Category: "Linux"
Filezilla on UbuntuがFTPSでエラー/パッチ投稿
Link: https://bugs.launchpad.net/ubuntu/+source/gnutls26/+bug/1261459
FTPクライアントのFilezillaで、 vsftpdで運用するFTPサーバにFTP over SSL/TLSで接続すると、ディレクトリ一覧取得エラーになる事象が発生します。
これは、vsftpdがセキュリティ維持のために導入した、ssl_session_reuseにfilezillaが対応しているものの、新しいバージョンのGnuTLSの組み合わせではないと、有効に動作しないという問題のためです。
残念ながら、Ubuntu precise 12.04(LTS)や、Trusty 14.04 (LTS)に含まれるFilezillaでは、古いGnuTLS (gnutls26)に対してコンパイルをおこなっているために、このようなエラーになります。
バグトラッカーに対して、一行パッチを提出しました。
https://bugs.launchpad.net/ubuntu/+source/gnutls26/+bug/1261459
Ubuntu Precise 12.04 (LTS)を使っている方は、わたしのPPAから入手も可能です。
https://launchpad.net/~miurahr/+archive/ubuntu/ppa
OmegaTで英字郎を変換したStarDict辞書を使う
OmegaTでは、StarDict辞書を使えることを前回触れました。
前回は、英字郎の辞書ソース（TXT形式)をstardict形式に変換できました。
StarDictで使うためには、 /usr/share/stardict/dic/ へ、前回作製したファイルを配置することで使い始めることができます。
さて、OmegaTでは、プロジェクトディレクトリのdictionaryへ配置すれば良いことを前回に述べました。しかしながら、おそらくそのままでは、一向に利用できないものと思います。
というのは、
14101: 情報: Loaded dictionary from '/home/miurahr/translate/dictionary/reiji-136.ifo': 10490ms
14101: FINER: File '/home/miurahr/translate/dictionary/eiji-136.dict.dz' added
14101: FINER: File '/home/miurahr/translate/dictionary/reiji-136.idx' added
14101: FINER: File '/home/miurahr/translate/dictionary/reiji-136.dict.dz' added
14101: FINER: File '/home/miurahr/translate/dictionary/waei-136.idx' added
14101: FINER: File '/home/miurahr/translate/dictionary/waei-136.ifo' added
14101: エラー: Uncatched exception in thread [DirectoryMonitor]
14101: エラー: java.lang.OutOfMemoryError: Java heap space
14101: エラー: at java.util.Arrays.copyOf(Arrays.java:2271)
14101: エラー: at java.io.ByteArrayOutputStream.grow
(ByteArrayOutputStream.java:113)
14101: エラー: at java.io.ByteArrayOutputStream.ensureCapacity
(ByteArrayOutputStream.java:93)
14101: エラー: at java.io.ByteArrayOutputStream.write
(ByteArrayOutputStream.java:140)
14101: エラー: at org.omegat.util.LFileCopy.copy(LFileCopy.java:90)
14101: エラー: at org.omegat.core.dictionaries.StarDict.readFile
(StarDict.java:193)
14101: エラー: at org.omegat.core.dictionaries.StarDict.readHeader
(StarDict.java:95)
14101: エラー: at org.omegat.core.dictionaries.DictionariesManager.fileChanged
(DictionariesManager.java:96)
14101: エラー: at org.omegat.util.DirectoryMonitor.checkChanges
(DirectoryMonitor.java:156)
14101: エラー: at org.omegat.util.DirectoryMonitor.run
(DirectoryMonitor.java:96)
こんなふうにメモリ不足エラーになってしまうからなのです。
OmegaTは、いまのところ辞書をすべてメモリー上に読みこもうとします。
英字郎のように大きな辞書を読もうとすると、既定のメモリ上限にすぐに達してしまいます。
そこで、/usr/bin/omegatや/usr/local/bin/omegat（インストール方法によりパスは異なる）をエディタで開いて（スーパーユーザで編集してください）、メモリ上限を上げる必要があります。
既定では
#!/bin/bash
# readlink follows any symbolic links to get the real file
REALOMEGATPATH=`dirname "$(readlink -nf $0)"`
java -jar -Xmx512M "${REALOMEGATPATH}/OmegaT.jar" $*
こんなになっていますので
#!/bin/bash
# readlink follows any symbolic links to get the real file
REALOMEGATPATH=`dirname "$(readlink -nf $0)"`
java -jar -Xmx2048M "${REALOMEGATPATH}/OmegaT.jar" $*
のように上限設定を2GBへ変更してやります。 ３２ビットのWindowsなど、古いPCでは、利用可能なメモリが少な過ぎで利用できませんから、64bitのLinuxなど最新のOSと、メモリ搭載量の多い比較的新しめのPCを使ってみてください。
さて、これで辞書の利用はできるようになりますが、辞書引きが利用できるようになるために、最初にすごく時間がかかります。
37202: 情報: Loaded dictionary from '/home/miurahr/translate/dictionary/reiji-136.ifo': 6587ms
37202: FINER: File '/home/miurahr/translate/dictionary/eiji-136.dict.dz' added
37202: FINER: File '/home/miurahr/translate/dictionary/reiji-136.idx' added
37202: FINER: File '/home/miurahr/translate/dictionary/reiji-136.dict.dz' added
37202: FINER: File '/home/miurahr/translate/dictionary/waei-136.idx' added
37202: FINER: File '/home/miurahr/translate/dictionary/waei-136.ifo' added
37202: 情報: Loaded dictionary from '/home/miurahr/translate/dictionary/waei-136.ifo': 17402ms
37202: FINER: File '/home/miurahr/translate/dictionary/ryaku-136.idx' added
37202: FINER: File '/home/miurahr/translate/dictionary/eiji-136.ifo' added
37202: 情報: Loaded dictionary from '/home/miurahr/translate/dictionary/eiji-136.ifo': 45780ms
37202: FINER: File '/home/miurahr/translate/dictionary/ryaku-136.ifo' added
37202: 情報: Loaded dictionary from '/home/miurahr/translate/dictionary/ryaku-136.ifo': 5818ms
37202: FINER: File '/home/miurahr/translate/dictionary/ryaku-136.dict.dz' added
わたしの２０１０年ころの4コアの Core i7, SSD diskの利用でも80秒ほどかかっています。２GB分近くメモリ上にデータを読み込んで展開しているわけで、当然と思います。
このあたりは、辞書そのものをメモリーに読み込まず、一時ファイルに圧縮展開後、mmap するような作りにすべきだと思います。OmegaTはJavaで書かれているので、すこし難しいのかもしれないですね。
StarDictで英字郎をつかう
翻訳作業を多数行う方は、翻訳メモリを使っていることと思います。
商用では、Tradosが有名のようですが、もっぱら私はOmegaTを使っています。
OmegaTでは、辞書引きの機能があり、StarDict形式の辞書をプロジェクトのdistionaryディレクトリに配置することで、自動的に辞書を引いて画面に表示してくれるようになっています。
そこで、これまでEPWING形式の辞書をEBViewで閲覧していたのですが、StarDict形式の辞書を作って、利用することにしました。
既に、StarDict形式への変換について、複数の方がブログに書いています。
sora_hさんは、 http://codnote.blogspot.jp/2010/01/i-installed-stardict-and-eijiro.html PDIC for WinをLinuxでWINEを使って動作させ、変換することで作業していました。
Design Recipe 別館Blog http://blog.designrecipe.jp/2011/01/01/eijiro-stardict-memo/ では、短いRubyプログラムを使って、実現されていました。
TXT形式のオリジナルのデータを持っていますので、後者の方法を試すことにしました。
スクリプトpdic1line2tab.rbは次のとおりです
<pre>
#!/usr/bin/env ruby
# -*- coding: utf-8 -*-
ARGF.each do |line|
line.gsub!("■・", "\\n・")
line.gsub!(/■/, '')
attr = nil
line.sub!(/ \{(.+?)\}/) do |e|
attr = $1
''
end
key, content = line.split(' : ')
next if content == nil
content = "【#{attr}】" << content if attr
puts [key, content].join("\t")
end
</pre>
使い方ですが、辞書ソースをUTF8に変換し,改行コードも整形したうえで、このスクリプトを通します。
$ iconv -f SJIS-WIN -t UTF8 EIJI-136.TXT | sed -e 's/^M//g' | ruby pdic1line2tab.rb > eiji-136.tab
StarDict形式に変換するために、 stardict-toolsパッケージを導入します。
apt-get install stardict-tools
そして
$ /usr/lib/stardict-tools/tabfile eiji-136.tab
実行したeiji-136.tabファイルのあるディレクトリに、stardict形式の辞書ファイルが３つ出来ます。
さて、Ubuntu /Debianに含まれているStarDict-toolsは、3.0.2バージョンです。このバージョンには、レコードの重複を許さないという仕様が有ります。3.0.1までと、3.0.3以降は、重複OKであるため、これは仕様バグです。
https://code.google.com/p/stardict-3/issues/detail?id=37
実際にバグ報告３７番として報告され、修正されています。
Ubuntu/Debianのパッケージでは、この修正は含まれていませんので、パッチが必要です。
パッケージをソースからコンパイルすることで対応します。
パッチは、stardict-tools-tabfile-fix-issue37.diffを取得します。
以下は、パッケージの再ビルド例です。
$ apt-get source stardict-tools
$ apt-get build-dep stardict-tools
$ cd stardict-tools-3.0.2
$ quilt import ../stardict-tools-tabfile-duplication-fix-issue37.diff
$ quilt push -a
$ debuild -us -uc -b -i
できあがったパッケージをインストールしましょう。
$ sudo dpkg -i stardict-tools-3.0.2_2build2_amd64.deb
vagrantで作業中に、scpしたくなったら
Link: http://minimul.com/ssh-and-scp-into-a-vagrant-box.html
Vagrantは便利ですね。
vagrantで作業中にscpしたくなることがあります。virtualboxやkvmなど、ローカルのVMの時は、そんなに面倒ではありません。
しかし、AWSプロバイダーのようにクラウドを使っている場合、アドレス等が決め打ちできないので、面倒デス。
そんな時は、vagrantでssh設定を生成すればいいのです。
vagrant ssh-config > ./vagrant.ssh.config
scp -F vagrant.ssh.config default:/etc/httpd/conf.d/ssl.conf ./
このようにすると、いちいちインスタンスのIPアドレスを調べなくても、SCPできます。やったー。
AWSにSSHログインでToo many authentication failuresエラー
Link: http://theandystratton.com/2012/ssh-returns-too-many-authentication-failures-error-hostgator
リンク先の記事のおかげで、問題が解決した件を記します。
情報セキュリティに敏感になってきたので、漏洩リスクを下げるために、SSHキーを使いわけるようになりました。
Publicキーについても、GithubやAWSなど、登録するサービスが有るのですが、別々にするようにしています。
そしたらですね、エラーがでるようになりました
Too many authentication failures for username
なぜそうなるかというと、Gnomeの環境では、.sshの下にあるSSHキーを、ログインのときにすべてssh-agentに登録するわけです。
sshログインの時は、ssh-agentに登録されているキーを順次適用してログインできるか試します。
あまりたくさんのキーが.sshの下にあると、上記のエラーになるというわけです（たくさんと言っても、５ことか６こでエラーになります）
Amazon Web Service EC2を使うと、ログイン用のKey Pairを、Webから創ることができます。
sshコマンドで、 -i オプションをつけることで指定できる、とされています。
しかし、上記のような事象が起こる環境ですと、-i オプションにつけた鍵を試す「前に」,ssh-agentに登録された鍵を試してエラーになっちゃうので、ログインできないという事象が起こります。
そのため、ここ１週間くらい、ちょっと悩んでしまいました。（調べる余裕なかったし）
でも割合簡単に解決しました。
ポリゴン処理
分散タイルサーバを実現するTileManプロジェクトで、つかうため lua-nginx-osm ライブラリというのを、コアライブラリとして開発しています。
この中で、次のような機能を実現しています。
- ポリゴン指定した地域をデータとして持っている。
- タイルサーバで、タイル要求されたX/Y/Zoomについて、 そのタイルが、（１）の地域に含まれているかどうかを判定する。
- 含まれている場合、タイルを生成する。
地域データは、geofabrikのデータを意識しています。
DBとして、特定の地域のデータだけPostGISに持っておいて、タイル要求がきたときに、それがDBに入っていればレンダリング実施、そうでなければ、アップストリームのtile.openstreetmap.orgへ要求、みたいな処理を実現しています。
これは、他の製品でもありそうな機能ですよね。
さて、上記の処理を行うために、is_inside_regionという関数を定義しました。計算速度を上げるために、
簡易なアルゴリズムを採用しました。ポイントは以下です
res = (y1 - y2) * nx + (x2 - x1) * ny + x1 * y2 - x2 * y1
(x1, y1) (x2, y2) は、地域を指定するポリゴンの一辺のベクトル
(nx, ny)は、判定するタイル要求の位置
上記は外積をとっており、全ての辺について判定して、すべて負でなければ、
すべての辺の内側に、判定するタイル要求の位置があることが分かります。
しかし、この判定ロジックには、弱点があり、比較するポリゴンは、かならず
convex polygon (凸多角形）である必要があるのです。
そこで、たとえば japan.kmlのような凹凸多角形(concave polygon)を凸多面体に分割することにしました。
単純なケースでは、手作業でも可能ですが、複雑になると、手作業では不可能になります。
このような問題は、計算幾何学で研究されていて、素晴らしいライブラリがすでに提供されています。
例えば、アルゴリズム設計マニュアルの下巻には、第17章計算幾何学の中に、１７．１１多角形分割 として解説されており、CGALというライブラリがつかえることが記されている。また、上記の判定についても、17.7 点位置決定で詳細に書かれている。
そこで、CGALを用いて、ポリゴンを複数の多角形に変換し、LUAのプログラムを生成するようなユーティリティプログラムを書くことにしました。
$ git clone https://github.com/miurahr/lua-nginx-osm.git $ cd lua-nginx-osm $ apt-get install libcgal-dev cmake make $ make
これでプログラムが生成されるはずです。実行は、
$ utils/poly2lua/poly2lua -t
ここで(-t)をつけると、テストモードで、内蔵の日本の定義データを元に、複数の多角形（緯度経度）を示すデータを生成します。
また、osm/data/*.kml が元データで、 osm/data/*.luaが生成された複数の凸多角形のデータです。
Linux kernel Hyper-V and Virtual-PC detection
static int prefer_ms_hyperv = 1;
module_param(prefer_ms_hyperv, int, 0);
static void piix_ignore_devices_quirk(struct ata_host *host)
{
#if IS_ENABLED(CONFIG_HYPERV_STORAGE)
static const struct dmi_system_id ignore_hyperv[] = {
{
/* On Hyper-V hypervisors the disks are exposed on
* both the emulated SATA controller and on the
* paravirtualised drivers. The CD/DVD devices
* are only exposed on the emulated controller.
* Request we ignore ATA devices on this host.
*/
.ident = "Hyper-V Virtual Machine",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR,
"Microsoft Corporation"),
DMI_MATCH(DMI_PRODUCT_NAME, "Virtual Machine"),
+ /* DMI_MATCH(DMI_BIOS_VENDOR, "VRTUAL"), */
},
},
{ } /* terminate list */
};
+ static const struct dmi_system_id find_virtual_pc[] = {
+ {
+ .ident = "Microsoft Virtual-PC",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR,
+ "Microsoft Corporation"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Virtual Machine"),
+ DMI_MATCH(DMI_BIOS_VENDOR, "American Megatrends Inc."),
+ },
+ },
+ { } /* terminate list */
+ };
const struct dmi_system_id *dmi = dmi_first_match(ignore_hyperv);
if (dmi && prefer_ms_hyperv) {
- host->flags |= ATA_HOST_IGNORE_ATA;
- dev_info(host->dev, "%s detected, ATA device ignore set\n",
- dmi->ident);
+ if (!dmi_first_match(find_virtual_pc)) {
+ host->flags |= ATA_HOST_IGNORE_ATA;
+ dev_info(host->dev, "%s detected, ATA device ignore set\n",
+ dmi->ident);
+ }
}
#endif
}
The patch is not tested and just a concept to fix problem.
You can escape the problem with kernel option 'ata_piix.prefer_ms_hyperv=0'.:: Next >>
