ノートPCだと回線状態が不安定だからか一向にアップグレードの準備が完了しなかったのだが、デスクトップPCであれば回線が早いと判断したのか予約して電源入れっぱなし数時間で準備完了していた。
バックアップもとっていたので、昨夜実施。時間がかかると思ってそのまま寝たら朝になっても昨夜と同じ進行状況で止まっていた！
一応SSDのアクセスは行っている模様だが、このあと10時間放置してそのままだったらやはりアップグレードインストールなんかするもんじゃないということで！
これまではすべてクリーンインストールしかしていないし、クリーンインストールでトラブルに遭遇したことも一度もない。
isoインストールでもプロダクトキーが必要だというので、一回はアップグレードインストールしなければならないという状況が改善されることを願う。
なぜならエラー画面が一瞬出たから(笑)
Tomcat6系はとっくにサポート切れかと思いきや、2016年年末までは大丈夫。
以下は公式サイトの引用であり、2016年末のサポート終了について記載されている。
The Apache Tomcat team announces that support for Apache Tomcat 6.0.x will end on 31 December 2016.
このサーバーは数年来さくらのVPSにて運営しているのだが、たまに仮想OS脆弱性対応とやらでメンテナンスが入る。
指定した時間までに仮想OSの停止をすれば、勝手にメンテナンスで止められることはない。
4年近く利用していて、たったの二回だから、AWSのインスタンス障害に比べれば全然頻度は低い。
ただし、ゲストOSの完全停止が必要とのことで、その間サーバーをどうするか？
お盆期間中でアクセスも少ないので、DNSを一時的に別サーバーに向けて503(メンテナンス)を出すことにした。
Webにあった情報を参考にさせていただき、時間の部分をカスタマイズ。
# カスタマイズしたメンテナンス画面のURL
ErrorDocument 503 /503error.html
RewriteEngine On
# 2015年08月11日 22:40~メンテナンスに入ります
RewriteCond %%{TIME} >201508112240
# メンテナンス画面と画像,js,cssをリダイレクトされるのを防ぐ
RewriteCond %{REQUEST_FILENAME} !(/503error.html|.(gif|png|js|css))$
# 503レスポンスする
RewriteRule ^.*$ - [R=503,L]
# メンテナンス終了時間をクローラーに伝える(←ここが重要)
Header set Retry-After "Wed, 11 Aug 2015 14:00:00 GMT"
DNSの切り替えが伝わるまでに20分ぐらいかかるし、その後も切り戻しでいくつかはつなげない時間もあったかもしれないが、無事再起動完了。
Tortoisesvnをインストールしたら「コンピューターにapi-ms-win-crt-runtime- 1-1-0.dllがないため、プログラムを開始できません。この問題を解決するにはプログラムを再インストールしてみてください。」とのメッセージがでてインストールできない。再起動しても毎回上記エラーが繰り返されるので、Tortoisesvnが必要としているDLLなのだろう。
というわけでネットで情報収集。どうやらVisual C++ のランタイムDLLをインストールすればよいらしい。
（ただし過去のTortoiseSVNでこれをインストールした記憶はない！）
https://www.microsoft.com/ja-jp/download/confirmation.aspx?id=48145
インストールしたら当然エラーは消滅した。
CF-S10のSSD交換は結構簡単(Let’s noteにしては)だったが、CF-SX1はちょっと難易度が高い。
まずHDDの厚さが7MMになっているので、SSDも7MMでなければ入らないし、隙間も少なくなっている。
バッテリーを外したところで、ねじを一本はずして、左にスライドすると、HDDが取り出せる。
HDDについているビニールを頼りにHDDをひっぱる。
このビニールは引っ張り出すのに必須なので換装するSSDにつけておく。
あとはSSDをもとの位置に戻すのだが、まずコネクターをつないでから、入り口をふさぐプラスチックのガードを広げなければならない。
これがなかなか難儀なので事前情報で調べておいたとおりに、使用済みプリペイドカードをで入口をひろげつつ、その中にSSDを通していく。
交換難易度としてはCF-S10より高いけど、素人でもできなくはないのでHDDモデルはさっさとSSDに換装してしまおう！
4月に購入していたというSSDをようやくCF-SX1に装着しようという試み。
なぜ今まで放置していたのかというと交換がめんどくさいとの評判だったため！
まず320GBのHDDを512GBのSSDに換装するため、今回は既存のHDDのパーティションを縮小する必要がない。
MARSHAL MAL-2935SBKを利用して、物理的に完全クローンする。
書き込み先がSSDのため多少早いかと思ったけど、70分かかってクローン完了！
Let’s noteは一時期ThinkPadとシェアを二分していたようだが、今や法人需要ではシェアNo.1であることは間違いないだろう。
法人モデルは比較的安定性を求められるためか、毎年モデルチェンジはするが、筐体は数年間ほぼ一緒だったりする。
つまりSSDの交換方法やメモリの交換方法が一緒というわけ。
(メモリの規格はDDR3 SO-DIMMで今のところほぼ変わらないため)
CF-S10シリーズは今となっては4年前のモデルとなってはいるが、以下のモデルとほぼ一緒の筐体。CF-Nシリーズは光学ドライブ(DVD)がないだけであとはほぼ一緒。
なお、バッテリーは細かい型番が違うので注意。
CF-S8
CF-S9
CF-N8
CF-N9
現在CF-S10の後継シリーズとなっているCF-SXシリーズだが、SX1からSX4までこれまた同じ筐体でバッテリーも一緒。本体側のメモリ交換には分解が必須となっているため、お手軽に16GBにしたいならCF-S10の方が良い。最近のモデルになるとCPUの省電力性能が上がったので稼働時間が伸びている。
CF-SX1
CF-SX2
CF-SX3
CF-SX4
CF-NX1
CF-NX2
CF-NX3
CF-NX4
CF-SX3のSSDモデルだと、バッテリーLで30時間稼働というが、本当かな？
中古の相場はCF-S10が3万円台から、SXシリーズはまだ高くて10万以上もざらにある。
あまり需要があるかどうかはわからないが、SSHDの待ち受けポートを複数あける技。
/etc/ssh/sshd_configを編集して、Portのセクションに開けたいポートを列挙するだけ。
Port 22 Port xxxxx
最小構成でインストールしたからか、いろいろなところで躓いてしまう。
firewallの設定を楽してCUIで実行しようとしてコマンドを実行したら、エラー発生
# system-config-firewall-tui
Traceback (most recent call last):
File "/usr/bin/system-config-firewall-tui", line 29, in <module>
import fw_tui
File "/usr/share/system-config-firewall/fw_tui.py", line 34, in <module>
import fw_nm
File "/usr/share/system-config-firewall/fw_nm.py", line 30, in <module>
bus = dbus.SystemBus()
File "/usr/lib/python2.6/site-packages/dbus/_dbus.py", line 202, in __new__
private=private)
File "/usr/lib/python2.6/site-packages/dbus/_dbus.py", line 108, in __new__
bus = BusConnection.__new__(subclass, bus_type, mainloop=mainloop)
File "/usr/lib/python2.6/site-packages/dbus/bus.py", line 125, in __new__
bus = cls._new_for_bus(address_or_type, mainloop=mainloop)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.FileNotFound: Failed to connect to socket /var/run/dbus/system_bus_socke
messagebusというサービスが動いていないのがエラーの原因らしいので、動かす
service messagebus start
gitでpushしたときに発生した上記エラー。
.gitconfigにはUSER名を定義しているのに何で？
該当ディレクトリに移動して、git remote -vしてみると
PUSHのエントリーが二つあり、片方にはユーザー名とパスワード情報がない。
しょうがないので、コマンドで直してみる。
git remote set-url origin http://USERNAME:PASS@GITURL/
今度はうまくいった。原因は不明！