サービスはDTIのServersMan＠VPSです。
既存のServersMan@VPSの鯖でSSLを導入しようとした所、SSLはインストールされているのに443ポートが反応しないし、そもそもSSL接続のairdisplayが死んでいるので、問い合わせてごたごたするより、さっさと乗り換えたほうが速いということで、新しく契約しました。
他のサービスに乗り換えることもちょっとは考えましたが、勝手が変わるとまた面倒なので同じサービスを追加ということに。
元の鯖はCentOS5.11で2017年3月でサポートも終わることだし、他のServersMan＠VPSの環境でCentOS6ではSSL接続が生きているので、似たよう環境にしようとCentOS6(64bit)環境で契約しました。
登録が完了して、しばらくしたら可動が開始したよなので、セットアップを始めます。
さぁ、またグダグダしますか。
またVPSを借りました。
新しい通販サイトの運営用です。
FTPサーバーとして使い慣れたProFTPdを選んだのですが、軌道に失敗します。
/etc/rc.d/init.d/proftpd start
Starting proftpd: [FAILED]
設定ファイルを見ても特におかしいところはないので、ログを見ようとしても追加されていない。
アプローチを変えてみると次のメッセージが表示された。
/usr/sbin/proftpd
- warning: unable to determine IP address of 'dti-vps-srv000'
- error: no valid servers configured
- Fatal: error processing configuration file '/etc/proftpd.conf'
※ DTIのServersman@VPSですが、サーバー番号000は実在しません、念のため。
どうも、自分をホスト名で検索して空振りなのでエラーとなっている模様。
# vi /etc/hosts
127.0.0.1 localhost.localdomain localhost dti-vps-srv000
::1 localhost.localdomain localhost dti-vps-srv000
と、hostsに追加。
/etc/rc.d/init.d/proftpd start
Starting proftpd: [ OK ]
無事に起動しました。
でめたし、でめたし。
ImageMagickのconvertコマンドでJPEG形式の画像ファイルををEPSファイルに変換したものを、Illustrator（イラストレータ） CS5で開くと、CS5が固まる問題を調査しました。
この現象を確認したのは、CentOS上で変換したJEPGファイルです。
昔はこんなことは無かった気がしますが、いつの間にかこの問題が発生していたので調査しました。
開発環境：
Windows7(64bit)
mageMagick 6.8.3-0 2013-02-13 Q16
Illustrator CS5
本番環境：
CentOS Linux 5.11
ImageMagick 6.2.8 05/07/12 Q16
CentOS上のImageMagickでJPEGファイルをEPSファイルにconvertしたものをイラレCS5で開くとイラレが固まって強制終了するしかなくなります。
単純に変換するときのコマンドです。
convert a.jpg a.eps
環境それぞれで生成されたEPSファイルを比較しました。
本番環境で生成したファイルにはヘッダ情報に
%begin_xml_code
<?xpacket begin="" id="W5M0MpCehiHzreSzNTczkc9d"?> <x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="Adobe XMP Core 5.0-c061 64.140949, 2010/12/07-10:57:01 "> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <rdf:Description rdf:about="" xmlns:xmpMM="http://ns.adobe.com/xap/1.0/mm/" xmlns:stRef="http://ns.adobe.com/xap/1.0/sType/ResourceRef#" xmlns:xmp="http://ns.adobe.com/xap/1.0/" xmpMM:OriginalDocumentID="xmp.did:A379835BBF2068118A6DF5258C3E39CC" xmpMM:DocumentID="xmp.did:660D7D5C2F0F11E3A9DB9D247D1C6687" xmpMM:InstanceID="xmp.iid:660D7D5B2F0F11E3A9DB9D247D1C6687" xmp:CreatorTool="Adobe Photoshop CS5.1 Macintosh"> <xmpMM:DerivedFrom stRef:instanceID="xmp.iid:A56F4D9AC92068118A6DF5258C3E39CC" stRef:documentID="xmp.did:A379835BBF2068118A6DF5258C3E39CC"/> </rdf:Description> </rdf:RDF> </x:xmpmeta> <?xpacket end="r"?>
%end_xml_codeというものが追加されていました。
MACのフォトショCS5.1で保存されたとの記載を確認できます。
簡単に言うとファイル情報ですね。
これを削除するとイラレは固まらずにファイルを開けます。
よ～くソースを見ると、
「%begin_xml_code」と「%end_xml_code」に挟まれた行、XMLで言うところの「<?xpacket />」がベタで書かれていました。
この行、ソースとしてはベタで書かれていてちょっと引っかかったので、行をコメントアウト、つまり先頭に「%」を追加すると、イラレで固まらなくなりました。
XMLをPostScriptにベタで書いているので構文エラーで固まっていたようです。
PostScriptにはヒアドキュメントはなかった気がするので、stremaとしてデータとして埋め込むか、1行ずつコメントアウトしてやらないとだめなのでしょう。
XML情報は特に必要がないので、除去するオプション「-strip」を追加してconvertしてみます。
convert a.jpg -strip a.eps
これでファイル情報が格納されなくなり、イラレで無事開けるようになりました。
ファイル情報が埋め込まれるかどうかはコンパイル時のスイッチ設定だとは思うのですが、そこまでガッツリ調べるのが面倒なので、回避方法を確認したところで良しとします。
でめたしでめたし。
CnetOSのセキュリティソフトとしてclamvを入れてあります。
実際にウィルスにおかされたことがないので、効果があるのかどうかもよくわかっていませんが。
最近気が付いたのですが、、いつのまにかcronのログに何やらエラーメッセージらしきものが現れていました。
[LibClamAV] Detected duplicate databases /var/lib/clamav/main.cvd and /var/lib/clamav/main.cld, please manually remove one of themざっと検索した感じでは、定義ファイルの持ち方がわかったとかで、古いものは削除してくれってことらしい。
ということで、削除します。
> cd /var/lib/clamav
> ls
bytecode.cld
daily.cld
main.cld
main.cvd
mirrors.dat
> rm main.cld
> rm main.cvd
> ls
bytecode.cld
daily.cld
mirrors.datこれで、cronにエラーが表示されなくなる…はず？
CentOS6は5と同じ要領では正常に進めません。
当然ですね、メジャーバージョンが違いますから。
簡単なパスの変更ですが、一応記録しておきます。
まずは、リポジトリのインストール
yum -y install yum-priorities yum -y install yum-plugin-priorities
次に、リポジトリ設定ファイルの編集
vi /etc/yum.repos.d/CentOS-Base.repo
各セクションの末尾に
#add
priority=1
を追加。
GPGキーをインストール
wget http://apt.sw.be/RPM-GPG-KEY.dag.txt rpm --import RPM-GPG-KEY.dag.txt
ここからがCentOS5と異なります。
RPMforgeリポジトリのインストール
64bitの場合
http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.2-1.el6.rf.x86_64.rpm rpm -ivh rpmforge-release-0.5.2-1.el6.rf.x86_64.rpm
32bitの場合
wget http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.2-1.el6.rf.i686.rpm rpm -ivh rpmforge-release-0.5.2-1.el6.rf.i686.rpm
そして最後にyumをアップデート
yum -y update rpmforge-release
これで、RPMforgeのお世話になれます。
でめたし、でめたし。
新しく鯖を手に入れました。
ウェブ鯖用なので、OSはCentOS6の64bitを選びました。
CentOS6の32bitはDVD1枚ですが、64bitはDVDで2枚になってしまうため、ネットワーク経由でインストールすることにしました。
ブートはUSBで、ネットワークインストールのISOをダウンロードしてブートイメージを書き込みます。
ブートするまでは特に問題ないでしょう。
インストールデバイスを選択する画面で手が止まりました。
見慣れたメニューと少し違います。
ローカルCD/DVD
ハードドライブ
NFSイメージ
FTP
HTTP
の、
FTPとHTTPがなくて、URLとなっています。
まぁ、想像は付くのですが、選択するとTCP/IPの設定画面が現れ、さらに進みます。
今までは、サイト名とディレクトリが分かれていましたが、URLを入力しろと言われます。
ここでhttpまたはFTPのプロトコルからの入力が必要になっています。
ま、大した変更ではありませんが、あえて統一した理由もよくわかりませんが。
そのあとはたぶん同じです。
変更があったかもしれませんが、その画面を利用するような設定ではなかったので。
これまでサーバ用途にはCentOS一択でお世話になっています。
RedHatが6になり、6.1も出るのに、CentOSは6のアナウンスが全然ないとか、中心メンテナが離脱してScientificLinuxへの移行を勧めているとか、物騒な情報も流れ迷走している感じがしなくもありませんでした。
そんな中でいよいよリリースされたCentOS6。
早速、余っているPCにインストールしてみました。
デザインや設定画面がちょっと変更になっていましたが、インストール自体は特に問題なく完了。
再起動して、yumでアップデートして、再起動して、特に問題はなさそうでした。
個人的な利用範囲での大きな変更は、PHPが5.3になってたり、Perlが5.10になってたりしているぐらいでしょうか。
これといって問題になりそうな更新もないので、今後はCentOS6のお世話になろうと思います。
PHPでPDFを扱うためのライブラリにTCPDFがあります。
TCPDFでOTFフォントを使用すると、AcrobatReaderでは正常に読めても、Illustratorで正常に読めず、テキストがラスタライズされて少々気持ちの悪い事態に遭遇することとなります。
Illutratorで開くことを想定しているなら、TCPDFで扱うフォントには少々の工夫が必要なので、ここに残しておきます。
まず、TCPDFで扱うフォントはTTFフォントで統一します。フォント名が同じであればTTFで作成したPDFでも、OTFフォントがインストールされた環境のIllustratorでも問題なく読むことが出来ます。
OTFフォントをTTFフォントに変換するにはFontForgeを使用します。
インストール方法を検索すると、Windowsのcygwin環境下でのインストール方法が沢山ヒットしますが、個人的にはうまくいかなかったので、LinuxのCentOS5を使用しました。アプリケーションはGUIでx11環境が必要なので、デスクトップ版を用意しましょう。
パッケージはhttp://sourceforge.net/projects/fontforge/files/fontforge-executables/から「fontforge-20090923-1.i386.rpm」をダウンロードします。少々古いものですが、特に問題ありません。ダウンロードが終わると、ファイルをダブルクリックするだけでインストールが始まり、あっさりと完了します。
アプリケーションはGUIなのですが、メニューには登録されませんのでファイルを直接起動するか、ターミナルから起動する必要があります。ターミナルで「fontforge」と入力して起動すると、読み込むファイルを要求されるのでTTFフォントに変換したいOTFフォントを選択します。
選択したOTFファイルの内容によってはCIDマップファイルが必要と言われるかもしれません。CIDマップファイルはhttp://fontforge.sourceforge.net/cidmaps.tgzにありますので、ダウンロードして展開したファイルを「/usr/share/fontforge/」にコピーします。
しばらくして読み込みが完了すると文字コード表が表示されるので、メニューより「CID＞単一化」を選択してファイルを統合します。
そしてメニューより「ファイル＞フォントを保存」を選択して、保存形式を「TrueType」に設定し、保存ファイル名を入力して保存すれば完了です。
これで変換作業は完了です。作成されたTTFファイルを開いて正常に読み込むことができれば成功です。
フォントファイルをTCPDFで扱える状態にする方法は、ライブラリ内のtcpdf/fonts/utils/README.TXTにある通りで問題ありません。むしろ他に方法がありません。
「$ ttf2ufm -a -F myfont.ttf」
「$ php -q makefont.php myfont.ttf myfont.ufm」
これで作成されたファイルをfontsディレクトリにコピーし、TCPDFよりPDFを作成すればAcrobatReaderでもIllustratorでも問題なく開くことが出来るPDFファイルの完成です。
いまいち文章が推敲されていないのでまとめます。
TCPDFはPDF作成ライブラリですごい
TCPDFのPDFはOTFフォントを使うとIllustratorでは読めない（ラスタライズされる）ことがある
TCPDFのPDFをＩｌｌｕｓｔｒａｔｏｒで読む可能性があるならOTFフォントをTTFフォントに変換しておく
OTFフォントをTTFフォントに変換するにはFontForgeを利用する
CIDマップがないとOTFファイルを展開できない（ことがあるかもしれない）
CentOS5.5のシステムをセットアップしていました。
yumからシステムを一通りアップデートしてから、PerlをCPANでモジュール群を更新したのですが、Image::Magickを入れようとしたところ、force installにしてもNOT OKとなり、インストールできませんでした。
これはImageMagickのバージョンとPerlの（コアなモジュール）バージョンとの依存の影響と思われ、Windowsの場合はImageMagickとActivePerlのバージョンは細かく指定されています。
Linuxの場合は自動で依存を解消してくれるものと思っていましたが、どうやらダメだったようです。
ImageMagickのために、別のディストリを入れなおすことも考えましたが、それではあまりにも情け無いので、だめもとで手動でソースからコンパイルしてインストールに挑戦しました。
まずはソースの取得
[root@localhost ~]# wget ftp://ftp.kddilabs.jp/graphics/ImageMagick/linux/SRPMS/ImageMagick.src.rpm
--2010-07-20 15:44:05-- ftp://ftp.kddilabs.jp/graphics/ImageMagick/linux/SRPMS/ImageMagick.src.rpm
=> `ImageMagick.src.rpm'
ftp.kddilabs.jp をDNSに問いあわせています... 192.26.91.193
ftp.kddilabs.jp|192.26.91.193|:21 に接続しています... 接続しました。
anonymous としてログインしています... ログインしました!
==> SYST ... 完了しました。 ==> PWD ... 完了しました。
==> TYPE I ... 完了しました。 ==> CWD /graphics/ImageMagick/linux/SRPMS ... 完了しました。
==> SIZE ImageMagick.src.rpm ... 8747108
==> PASV ... 完了しました。 ==> RETR ImageMagick.src.rpm ... 完了しました。
長さ: 8747108 (8.3M)
100%[======================================>] 8,747,108 3.39M/s 時間 2.5s
2010-07-20 15:44:08 (3.39 MB/s) - `ImageMagick.src.rpm' へ保存終了 [8747108]
検索してヒットするサイトの中にはURLが「kddilabs」ではなく「kddlabs」とありますが、どちらでもいい（？）みたいです。こちらの環境でkddlabsはDNS解決できませんでしたがkddilabsでは通りました。
ここからsrc.rpmを取得して展開します。
コマンドなら次の通り
[root@localhost ~]# rpm -ivh –nomd5 ImageMagick.src.rpm
1:ImageMagick 警告: ユーザ cristy は存在しません – root を使用します
警告: グループ cristy は存在しません – root を使用します
########################################### [100%]
警告: ユーザ cristy は存在しません – root を使用します
警告: グループ cristy は存在しません – root を使用します
同じ階層に「_FILES」という文字が追加されたディレクトリがあるはずなので、移動します。
[root@localhost ~]# cd ImageMagick.src.rpm_FILES [root@localhost ImageMagick.src.rpm_FILES]# ls ImageMagick-6.6.3-0.tar.bz2 ImageMagick.spec
とりあえずビルドしてみます。
[root@localhost ImageMagick.src.rpm_FILES]# rpmbuild -ba ImageMagick.spec
エラー: ビルド依存性の失敗:
libtiff-devel は ImageMagick-6.6.3-0.i386 に必要とされています
giflib-devel は ImageMagick-6.6.3-0.i386 に必要とされています
perl-devel >= 5.8.1 は ImageMagick-6.6.3-0.i386 に必要とされています
ghostscript-devel は ImageMagick-6.6.3-0.i386 に必要とされています
djvulibre-devel は ImageMagick-6.6.3-0.i386 に必要とされています
libwmf-devel は ImageMagick-6.6.3-0.i386 に必要とされています
jasper-devel は ImageMagick-6.6.3-0.i386 に必要とされています
libtool-ltdl-devel は ImageMagick-6.6.3-0.i386 に必要とされています
lcms-devel は ImageMagick-6.6.3-0.i386 に必要とされています
librsvg2-devel は ImageMagick-6.6.3-0.i386 に必要とされています
いろいろと足らないと文句を言われました。
とりあえずyumで片っ端から入れていきます。
[root@localhost ImageMagick.src.rpm_FILES]# yum install libtiff-devel giflib-devel perl-devel ghostscript-devel djvulibre-devel libwmf-devel jasper-devel libtool-ltdl-devel lcms-devel librsvg2-devel
進捗は省略します。
最終的に次の3つが残ります。
perl-devel >= 5.8.1 は ImageMagick-6.6.3-0.i386 に必要とされています djvulibre-devel は ImageMagick-6.6.3-0.i386 に必要とされています jasper-devel は ImageMagick-6.6.3-0.i386 に必要とされています
まず、「perl-devel」はcentOS5.5ではperlに頭語されているらしいので不要です。
specファイルの15行目（辺り）にあるperl-develを削除またはコメントアウトします。
次に、「djvulibre-devel」はリポジトリ「RPMForge」または「Dag」を利用してインストールします。
導入方法は検索するなどして調べてください。
大量に解説サイトがあるので省略します。
最後に、「jasper-devel」は「http://dev.centos.org/centos/5/testing/i386/RPMS/」にCentOS5用のRPMがあります。他のサイトにある通常のel5.i386のrpmは依存解消できずにインストールできませんでした。
これら3つが解決すれば晴れてImageMagickのコンパイルが開始できます。
[root@localhost ImageMagick.src.rpm_FILES]# rpmbuild -ba ImageMagick.spec
かなり時間がかかります。
問題なく終われば、以下の場所にrpmが生成されます。
[root@localhost redhat]# cd /usr/src/redhat/RPMS/i386
[root@localhost i386]# ls
ImageMagick-6.6.3-0.i386.rpm ImageMagick-devel-6.6.3-0.i386.rpm
ImageMagick-c++-6.6.3-0.i386.rpm ImageMagick-doc-6.6.3-0.i386.rpm
ImageMagick-c++-devel-6.6.3-0.i386.rpm ImageMagick-perl-6.6.3-0.i386.rpm
ImageMagick-debuginfo-6.6.3-0.i386.rpm
ここまで来れば（おそらく大丈夫です。
[root@localhost i386]# rpm -Uvh ImageMagick-*
準備中... ########################################### [100%]
1:ImageMagick ########################################### [ 14%]
2:ImageMagick-c++ ########################################### [ 29%]
3:ImageMagick-perl ########################################### [ 43%]
4:ImageMagick-debuginfo ########################################### [ 57%]
5:ImageMagick-devel ########################################### [ 71%]
6:ImageMagick-c++-devel ########################################### [ 86%]
7:ImageMagick-doc ########################################### [100%]
[root@localhost i386]# convert -version
Version: ImageMagick 6.6.3-0 2010-07-20 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2010 ImageMagick Studio LLC
Features:
でめたしでめたし。お疲れ様でした。
SSHも便利なのだろうが、クライアントの設定も必要なので使ってない。
基本的な設定などはWebminですむので特に問題はないが、あえてGUIで操作したいときにはVNCが重宝する。
自宅のネットワークにあるLinuxは全てVNCで操作しているが、たとえば手元にない場合、VNCを使うにはどうすればいいのか試してみた。
Google先生が教えてくれたサイトの情報は古いものやどうでもいい質問掲示板などがヒットして、はっきりいって役にたたなかった。
まずVNCの基本からおさらい。
通常はVNCうを使ったリモートデスクトップ機能でログイン中のユーザの画面をそのまま扱えるが、これはログインしていなければならない。うっかり再起動したものなら、このリモートデスクトップ機能は使えなくなり、まったく操作できなくなってしまう。
そこで、リモートからログイン自体が可能にならなければならない。
とりあえず「vncserver」と入力してvncserverを起動してみると、初回ならパスワードを設定するよう求められる。
よくわからないまま放置しているがユーザごとにパスを変えられるのかはよくしらない。
次に、起動方法の設定を行う
ディスプレイ番号1をrootでログインする場合、「/etc/sysconfig/vncservers」に以下のように追加する
VNCSERVERS="1:root" VNCSERVERARGS[1]="-geometry 800x600 -nolisten tcp -nohttpd -localhost"
あらかじめコメントアウトされている2行をコピーして数値を書き換えるだけで問題ないだろう。
それでサービスを再起動する
/etc/init.d/vncserver restart
VNCサーバーの起動に成功すれば、手順として7割終了といってもいいだろう。
複数のディスプレイをサービスで起動する方法が良くわからないので、誰か教えてください。
ちなみに0はリモート用に予約されているのか使えないので1からとなる（みたい）
アクセスするにはこのディプレイ番号に5900を足したポートに接続することになる。
つまり1なら5901ポートなので、ファイアウォールの穴を開けるのを忘れないようにする。
オプションいついては良くわからないのでそのままにしてある。（だめじゃん）
かいても最後の番号が有効になるらしい。
さて、ここでVNC Viewerでリモート接続してみる。
サーバのIPが192.168.11.2だとすると「192.168.1.2:5901」で接続する。
接続できればパスワードを求められるので入力するとログインできる。
しかし、GNOMEになれているとTwmという見慣れないGUIが表示される。
GUIなので、ターミナルからコマンドを入れれば何でも起動するのだけれど、メニューがほしい。
というかGNOMEが使えればというか使えないと意味がないので、使えるようにする。
今までの設定はVNC Serverへのログインで、そのユーザではどう表示するかの設定をする必要がある。
通常と同じにしてくれればいいのに、いちいち設定しないとだめなのは少し面倒くさい。（やり方があるのかも？）
設定ファイルは「/root/.vnc/sstartup」にあるが、隠しファイルを表示しないと見えないので注意。
「twm &」とある行をコメントアウトして「gnome-session &」と追加する。
結論から言えばここまでで成功ですが、これより理解できないことが多いので箇条書きに書いておく。
GNOMEでログインできるのは1プロセスのみ？
すでにrootでログインしていてGNOMEを使っているとVNCではGNOMEが使えないので、twmの出来損ないのような画面になる。（「twm &」に戻せばtwmで正常になる）
ログインs知恵いるユーザをログアウトさせても、GNOMEが使えない状態が残る。
システムをリブートして誰もログインせずにリモートからつなごうとすると5901ポートではなく5900ポートでリモートから接続できるようになっている。そしてGNOMEが使える。さらに、直接ログインするとそのデスクトップのリモート機能は使えない。つまり、先にリモートでログインしてしまうとリモートデスクトップ機能はしぬ。しかも、うっかりリモートをログアウトするとリモートからは永久にログインできなくなる・・・
つまり、リモートでログインしたければ、直接ログインしてはならない、うっかりログインしてしまった場合は、一度ログアウトしてログインしなおしてリモートデスクトップ機能で共有するしか方法がないようです。
この現象はGNOMEを選択した場合に限られ、twmのままであれば関係ないようです。
ちなみにユーザが違う場合は・・・やっぱり同じ現象でだめでした。
つまり・・・どういうことだ？
SSHじゃないと誰もログインしていないマシンをリモートで操作することはできないのか？
な訳ないよな・・・
だんだん混乱してきた。
vncserversの設定でroot以外を設定するとリモートからのログインができなくなった。
これはrootでvncserverを起動したからで、ほかのユーザでログインするにはそのユーザでvncserverを起動してパスワードを設定しなければならないようだ。
つまり、rootユーザ限定の前提で考えた場合、
rootでvncserverのパスを設定する。
vncserversの設定はパス設定済みのユーザを指定しなければならない。
vncserversで設定したユーザで一度ログインしてしまうとリモート系の機能は麻痺する(らしい）
う～ん、わかったようなわからないままのような。
まぁ、リモートで操作する前提なら直接ログインすることはないだろうから・・・
でもいざというときが怖いですね。やっぱりSSH入れろってか？orz=3