Linuxで新たなロジクールのUnifyingデバイスをペアリングする

最近はもっぱら、ロジクールの無線キーボードやマウスを愛用しています。

新しいデバイスを買った時、付属のドングルで使うぶんにはいいのですが、 既存のUnifyingレシーバに新しいデバイスを登録(ペアリング)したい場合、 公式のソフトはWindows用しかありませんので、Windowsでやれば手っ取り早いです。

しかし、どうしてもLinuxでそれをやりたい場合、どうするか。

GTK3の使えるディストリようには、この記事のように、GUIの使いやすそうなアプリがあるみたいですが、GTK3のないRHELのようなディストリ用にコマンドラインだけでできる方法もこのサイトで解説されています。

上記のリポジトリをcloneしてコンパイルするとUnifyというコマンドができますので、

# ./unify /dev/hidraw0

みたいに打ちこめば、USBに挿したUnifying Receiverがペアリングモードになるので、追加したいデバイスのスイッチをONにすれば、次の瞬間から使えるようになりますね。

いや〜便利便利。

ところで、つい前日買ったM185のことなんですが、仕事に持っていくつもりだったので、Unifyingにこだわらず安いのを、ということでこれにしたんですが(でも、ホイールがチルトできないのでちょっと失敗した感)、メーカーサイトでもとくにUnifyingとは書いてないくて、製品に付属してきたドングルも専用のものっぽかったんですね。

でも、本体を裏返してみたら、見慣れたマークが。

2013-12-08 15.20.51

おお、この赤いマークは、Unifyingの印ではないか!

ということでやってみたら、Unifyingレシーバーともちゃんとペアリングできるし、問題なく使えるようです。

Fedora 19 で google-chrome の web アプリが立ち上がらない

chrome に Tweetdeck というエクステンションがあって、PC から Twitter するときはほとんどコレを使っている。 chrome には web ページをアプリケーション化する機能があり、かの Tweetdeck もアイコン化してこれをクリックすれば立ち上がるようにしているのだが…

Screenshot from 2013-07-07 21:48:55

お試しでインストールしてみた Fedora 19 でも当然そのようにセットアップしたのだが、このアイコンをクリックしても Tweetdeck が立ち上がらない。

Screenshot from 2013-07-07 22:02:54

/opt/google/chrome/chrome: error while loading shared libraries: libudev.so.0: cannot open shared object file: No such file or directory
# ldd /opt/google/chrome/chrome | grep udev
libudev.so.0 => not found

なるほど、libudev.so.0 が無いと。Ubuntu 13.04 でもそんな問題があったな。でも、単独で chrome は立ち上がる不思議。

やはり F19 のリポジトリでは、 libudev.so.1 は提供されているものの libudev.so.0 は見当たらない。

では、むりくり symlink しちゃえ!

# cd /usr/lib64
# ln -s libudev.so.1.3.5 libudev.so.0
# ls -l libudev.*
lrwxrwxrwx. 1 root root    16  7月  7 22:12 libudev.so.0 -> libudev.so.1.3.5
lrwxrwxrwx. 1 root root    16  7月  4 01:54 libudev.so.1 -> libudev.so.1.3.5
-rwxr-xr-x. 1 root root 76456  6月 25 00:31 libudev.so.1.3.5
# ldd /opt/google/chrome/chrome | grep udev
libudev.so.0 => /lib64/libudev.so.0 (0x00007f0e537d5000)

というわけで、Fedora 19 でも無事 Tweetdeck が使えるようになりました。

OS で蹴るサイトを華麗にスルー

KDDI のお客様サポートのサイトは、なんと驚くべきことに、Windows(と MacOS?)以外のOSを蹴っており、 Linux ではログインできない。

それだけのために UserAgent を詐称するエクステンションを導入するのはしゃくにさわるので、Firefox のプロファイルフォルダの user.js に以下のように追加して、騙してスルーしよう。

Firefox のバージョンによってもデフォルトの Useragent 文字列は変わるので、確認くん などで default の Useragent 文字列を調べて、カッコの次に “Windows NT 6.3;” などと加えて、騙すための Useragent 文字列を得る。

btrfs で各 Linux ディストリの root を subvol で分けてみた

今までは、各ディストリごとにパーティションを切ってインストールしていたのですが、 空き領域とかもったいない気がしたので、 Fedora 19 をお試しインストールするのをいい機会に、 /boot こそは各ディストリごとに分けるけども rootfs は btrfs に subvol で領域は区別するものの同じ btrfs パーティションにインストールしてみるようにしました。

Screenshot from 2013-07-06 00:39:52

試してみるに、 Fedora 19 は btrfs 上の subvol 名を明示してインストールが可能、 Ubuntu 13.04 は subvol 名は固定(@, @home 等)になっちゃうけど btrfs 上の subvol にインストール可能、 しかし、 openSuSE 12.3 は、問答無用でインストーラが btfrs 上のルートにインストールしてしまったので、後で別の Linux から subvol を作ってそっちに全部 mv する作業が必要になったものの、とりあえず subvol の rootfs をマウントすることが可能であった。

(注)あとで気がついたけど、openSuSE の場合、あらかじめ subvol を作って set-default しておけばもっと簡単にできたのかも… 面倒くさいので確かめてませんが…

効率的にパーティションを共有することができて、しょっと幸せ。

Cherokee と SELinux と私

何ヶ月もブログを黙り込んでいて、久しぶりに更新したかと思ったらこんな話題です、すいません。

Cherokee という Web サーバがあって、設定をブラウザで GUI で行うので自称プロフェッショナルな人たちには敬遠されがちなソフトと聞き及んでいるが、たったそれだけで毛嫌いするには惜しいほどクールなソフトので、アンチメジャー派でもある私は Cherokee を結構気に入っていたりする。

今回は Windows Azure の無料お試しプランのサーバに CentOS 6.3 をインスコして、そこに EPEL から持ってきた Cherokee をインストールして動かそうと思ったら簡単に行かなかったので、そこらへんのメモ。 対処法としてすぐに SELinux を切ろうとするのは馬鹿がやることなので真似しないように

設定用 GUI の cherokee-admin に繋がらない

これは、chrokee-admin の起動オプションに

# cherokee-admin -t

と、-tを指定して起動すると解決する。デフォルトのポートの 9090 はすでに SELinux のポリシーで別のサーバ用に定義されているし、たかが設定時にしか起動しないプログラムのためにポリシーをいじるのは癪なので、アドホックに回避する。

PHP の CGI が動かない

これは、 cherokee が自動的に起動する FCGI の php-cgi が開くデフォルトの TCP 47999番ポートを SELinux が邪魔して接続できないためなので、

# yum install policycoreutils-python #(必要に応じて)
# semanage port -a -t http_port -p tcp 47999

として繋げられるようにしてやる。

念の為に、restorecon も実行しておく。

# cd /var/www; restorecon -R

FreeBSDにVirtualBox-OSEをインストールしてWindowsを入れてみた

今はファイルサーバとして FreeBSD を Headless(モニターに繋げない)な形で運用しているのですが、ためしに VirtualBox-OSE をインストールして Windows XP を入れてみました。

で、デスクトップの Ubuntu から VNC でつなげて操作。ローカルとはいえ、ネットワーク越しだとすごく遅いですね(^_^;)

でも SUGEEEEEEEE!!!!!!

FreeBSD 機は Shuttle XS-35 で Atom ファンレス機なので超静かです。

Fedora 17 に node.js をインストールする

Fedora の公式リポジトリにはまだ node.js は来ていないようですが、パッケージを用意してくれているサイトがありますので、これを野良リポジトリとして登録してインストールすると手っ取り早いです。

yum localinstall --nogpgcheck http://nodejs.tchol.org/repocfg/fedora/nodejs-stable-release.noarch.rpm
yum install nodejs npm

ただ、すでに node というコマンド名 (/usr/sbin/node) を含むパッケージ(アマチュア無線用?)があって、nodeコマンドの名前がかち合ってしまうので、上記のパッケージでは node コマンドではなく、 nodejs という名前のコマンドになっています。既存の node.js のパッケージ(npmでインストールするやつ)はだいたい、node という名前を期待しているので、

sudo ln -s /usr/bin/nodejs /usr/local/bin/node

などとしてから、PATHを調整して /usr/local/bin/node がまっさきに見つかるようにするか、アマチュア無線用のパッケージの方の node を remove しても良いでしょう。

yum remove node

couchdb-pythonでプログラムの中からセキュリティ設定をしたい

couchdb-pythonをいじってみたりしてるんですが、標題のことをしようと思って調べてました。所詮、couchdbのインターフェイスはHTTPなので、HTTPリクエストを組み立ててサーバに投げれば出来ることは出来るんですが、せっかくできあいのライブラリがあるんだし、もっとお手軽にできないものかと思ってソースを読んでみました。

結論。

couchDBのwikiに解説されているとおり、あるデータベース(仮に’database’とする)のアクセスにユーザ名・パスワードが必要になるようにするには、http://server:5984/database/_security に

{
   "readers" : {
     "names" : ["takeshi"],
   }
}

のようなJSON文字列をPUTすれば良いのですが、db.createを使って普通のドキュメントのように ‘_id’ に ‘_security’ を設定して呼んでも、アンダースコアで始まる _id ではエラーになってしまいます。そこで、python-couchdbライブラリのUndocumentedなメソッド couchdb.client.Database.resource.put を使って設定します。

import couchdb
server = couchdb.client.Server('http://admin:[email protected]:5984/')
db = server.create('database')
db.resource.put('_security',
                {'readers' : {'names' : ['takeshi']}},
                {'Content-Type': 'application/json'})

というような感じで、couchdb.client.Databaseクラス下のメソッドで簡単にPUTリクエストをサーバに投げることができました。あ、takeshiさんのパスワードは /etc/couchdb/local.ini に書いておきます。または、Futonインターフェイスからサクッとパスワードの設定をすることもできます。

Eclipse に ADT Plugin インストール時に依存関係でつまづく

Fedora 17 のベータ版を試しているところであるが、yum でパッケージからインストールした eclipse に、Android SDK の ADT Plugin をインストールしようとすると

requires plug-in "org.eclipse.wst.sse.core"

とか言われて、依存関係でインストールできなかった。ググってみると、eclipse.org の update サイトを有効にすれば依存関係を解決できて ADT Plugin もインストールが可能ということはわかったが、それでは、なぜ Fedora 17 のデフォルトではそういった update サイトが無効化されているのだろうか?

これは多分、eclipse のアップデート機能と、 yum によるシステムのアップデート機能がバラバラに働いてしまうことを避けるためにそういう無効化が行われているのであろうことは簡単に想像がつく。これは、perl -> cpan, python -> pypi, php -> pear, pecl などの対応でも同様である。なるべく yum update で一気に行いたいから、cpan や pip でインストール/アップデートするのではなく、パッケージとして用意されている。

だから、僕は上に書いたような解決方法は試したくない。

というわけで、org.eclipse.wst.sse.core を提供しているパッケージを調べてみると、eclipse-wtp-sourceediting.noarch であることがわかった。というわけで

yum install eclipse-wtp-sourceediting.noarch

で解決。ADT Plugin がインストールできるようになった。

Sun Java VM で日本語フォントを好みのものにしたい

ちまたの解説でよく見られるのが、fallback を設定してそこにフォントファイルをコピーするというものですが、たとえば、sazanamiフォントやVLゴシックフォントも(様々な事情で)インストールしてあるんだけど、Java VM では IPA モナーフォントを使いたいなぁ、というときに破綻します。

そこで、fontconfig.properties 設定ファイルを直接いじっちゃって解決してしまいましょう。

ファイルの場所は、Ubuntu だと /usr/lib/jvm/java-6-sun/jre/lib、 Fedora だと /usr/java/latest/jre/lib あたりでしょうか。

まず、fontconfig.*.bfc ファイルが認識されないようにリネームしてしまいます。bash(root) にて

# for file in *.bfc; do mv $file ${file%%.bfc}.bfc.bak; done 


fontconfig.properties.src を fontconfig.properties にコピーして

# cp fontconfig.properties.src fontconfig.properties 


fontconfig.properties ファイルの最後に以下の内容を書き足します。

awtfontpath.japanese=/usr/local/share/fonts
allfonts.japanese=Mona
filename.Mona=/usr/local/share/fonts/ipagui-mona.ttf
sequence.allfonts.UTF-8.ja=latin-1,japanese


お好みフォントファイルの名前や場所などはあなたの環境に合わせて書き変えてください。

おしまい。