DynDNSの軍門に降るか^^;

mooo.com, x64.meという二つのドメインを試してきましたが,どちらも世間的には,SPAMサイトと認定されているようです.Googleの検索エンジンも来てくれません.

最近,mydns.jpを試していますが,登録はできますが,どうしたもんか,DNSに反映されてきません.

年額USD25払って,je1sgh.dyndns.infoに戻すのが一番楽なようです.

KDE 4.13難航

Qt 5.3.0のbuildは,

export CFLAGS="-O2 -march=i486 -mtune=i686"
export CXXFLAGS="-O2 -march=i486 -mtune=i686"
export OPENSOURCE_CXXFLAGS="-O2 -march=i486 -mtune=i686"
./configure \
 -confirm-license \
 -opensource \
 -prefix /usr/lib/qt5 \
 -system-libpng \
 -system-libjpeg \
 -system-zlib \
 -system-sqlite \
 -plugin-sql-sqlite \
 -plugin-sql-mysql \
 -dbus \
 -nomake examples \
 -no-separate-debug-info \
 -no-pch

という,SLackwareのQt4.xのオプションから,エラーがでるものを外して,2台で試し,1台でOKでした.もう1台は,ネット検索であちこち見つかるように,webkitのbuildができません.

ネット検索で解るように,webkitを外すオプションはありません^^; やむなく,qtwebkitとそのexmampleのサブディレクトリーをどかして^^; build成功しました.

しかし,KDE 4.13はうまくいきません.kdelibsで必須となるAtticaがbuildできません.情報を収集してみます.Qt 5.2.xに退化させた方がいいのかな.

KDE 4.13は要Qt5

しばらくKDE 4.12のupdateをサボっていたら,KDE 4.13がリリースされていたので,あいまにインストールして見ることにしました.

それで,KDEの関連ソフトのupdateから始めましたが,ひとつのソフトは,CMakeが古いといって,エラーを出します.CMakeをgitレポジトリーから最新のものをpullしてインストールしたら,3.0になりました.この件は解決.

また,Sopranoかなんかをbuildしているときに,ECMがないというので,調べてみたところ,これもKDEのサポートソフトウェアで,extra-cmake-modulesというもので,KDEのgitレポジトリーにありました.これも解決.

で,まあ,いつものこんな調子で必要な条件を満たすべく,git pullしたり,cmakekdeしたり,時には,git cloneして,関連ソフトがそろったので,buildのディレクトリーと,インストール先の/opt/kde4を削除して,KDEの一番根幹であるkdelibsのbuildをはじめました.

そしたら,atticaがないとほざきます.atticaのソースディレクトリーに行ってcmakekdeすると,Qt 5がないといいます.

いままで,Qt 4でやってきましたが,KDE 4.13からは要Qt 5のようです.

ということで,一息入れてから,Qt 5のbuildをしてみます.Qt 4と同じやり方で行くといいんですが^^;

あくまでこのサイトに書いてある情報の利用は自己責任でお願いします.

追記

要Qt5は間違いです.

Too Big To Fail

大きければ良いってもんじゃないって事を実感しました.

今回のOpenSSLの史上最悪のセキュリティーホール対策の話です.まあ,私が運営しているサイトなんか,意図的なクラックの対象にはならないと思いますが,そのうちネットをクロールしながら,総当たり的にクラックするツールなりウィルスが発明されて,どんなサイトも攻撃対象になり得ますので,対策を取っておきました.

対策の第一は,OpenSSLのupdateです.ふだんからソースからbuildしてますので,たいした手間ではありませんでした.

そして,サーバーの秘密鍵の更新です.サーバーの秘密鍵が盗まれても何の形跡も残らない,というこで,完全を期すならば,OpenSSLのupdateのあとにこの鍵の更新をすることが推奨されています.

証明書は,私の利用しているところは有効期限が半年なので,5か月内外で更新していますが,秘密鍵そのものは滅多に作り直すものでは無くて,タイムスタンプを見たら,どのサイトのものも2006年作成でした.で,自分のメモにしたがってやってみました.

メモには,キーのサイズを4096にするとあるのですが,前にキーを作ったのは,8年も前ですから,この際8192にしてみました.

私が管理しているサイトでは,httpd(HTTPS)の他,imapd(IMAPS)とsendmail(STARTTLS)がこの秘密鍵とそれぞれの証明書を使用しています.それら3つのサービスの秘密鍵と証明書を更新してデーモンを再起動しました.

httpdに関しては何ら問題がありませんでしたが,IMAP(IMAPS)とSMTP(STARTTLS)で接続できないとか認証エラーがクライアントから出ます.

昨夜から今朝までさんざん悩んで,sendmailをソースから再ビルドしたり,SASLのパスワードを設定し直したりしてみましたが,ちっとも症状は変わりません.ふと思いついて,

sendmail error 8192

で検索したらありました.キーサイズは4096までじゃないとsendmailのSTARTTLSは正常に動作しないようです.この他,IMAPS対応のメールクライアントやデーモン,プラグインでもNGなものがあるようです.

Heartbleed
ただし,HTTPSは正常に機能していましたが,DAVは動かなくなっていました.