クエリーログでサーバが容量不足に

さくらVPSで使っているDebianのサーバにログインしたところドライブの空き容量が無いと警告が表示された。容量の大きいファイルを検索したところ /var/log/mysql.log35GB になっていた。

契約しているのは50GBのプランで df -h コマンドだと46GBの容量と表示される。つまり容量の7割をmysqlのログファイルで占めていたことになる。このログファイルと不必要なバックアップファイルを5GBほど削除し、整理したところ空き容量ゼロの状態から空き容量38GBに落ち着いた。

原因

  • クエリログの出力が有効になっていた
  • クエリログの出力先が /var/log/mysql.log になっていた
  • /etc/logrotate.d/mysql-server が参照するファイルが /var/log/mysql/mysql.log であったためログファイルがローテートされていなかった

クエリログについては何かのトラブルの調査で出力するように設定して、そのままになっていたのではないかと思っている。基本的に dotdeb のパッケージでインストールした my.cnf をベースに設定していたはずなのでいつの間にか出力先が /var/log/mysql/*.log に変わってログローテートの対象から漏れたのかもしれない。

年末年始でパッケージをアップデートしておこうかと思ってログインして気がついて良かった。パッケージを大きくバージョンアップするときにはパッケージのデフォルトの設定ファイルと現行の設定ファイルを比較すべきだし、そうしていたつもりだが、ログファイルのパスなど機能の動作を変える設定ではないものは見落としがちだ。

Windows 10でNASが見えなくなりSambaを有効化して解決

Windows 10で気がついたらNASに接続できなくなっていた。たまにしかNASを使っていなかったので、いつから起きていたか不明。調べるといろいろな解決方法がインターネット上で公開されていたが、その中から「Sambaのクライアント機能を有効にする」方法で見えるようになった。

問題の状態をまとめると

  • NASのサーバがネットワーク > コンピュータに表示されない
  • ネットワーク > メディア機器には表示されている
  • ¥¥サーバー名 を打ち込んでもエクスプローラーで開けない
  • ¥¥IPアドレス を打ち込んでもエクスプローラーで開けない
  • 認証をかけていない共有フォルダも開けない
  • pingは通る
  • http://IPアドレス でNASの管理ページは開ける
  • Macからは開ける

pingは通るし、NASの管理ページはブラウザで開けるのでネットワーク的に到達できることは間違いなかった。他のMacのマシンからは参照できるのでNASが稼働していることも確認。

検索すると「[Windows 資格情報の追加]に認証で使うID/PWを設定する」という解決案が見つかったが、解決しなかったし、そもそも認証の必要のないフォルダも見れないのでこの問題でもないだろうとは予想していた。

結論としては「Samba機能を有効にする」という解決策を見つけて、実施したら直った。SambaとはWindowsから使えるフォルダ共有の仕組みで、多くのLinuxサーバのNASはWindows PCにファイルサーバとして機能を提供する際にSambaを使う。

何故Sambaが無効になっていたのかはわからないがマイクロソフトの以下の記事をみていると、「Windows 10 Fall Creators Update」を適応してから問題が起きるようになったのかもしれない。

Windows 10 Fall Creators Update と Windows Server バージョン 1709 の既定では SMBv1 はインストールされません

Sambaのクライアント機能を有効にする方法

  1. Windowsメニューを右クリックして 「アプリと機能(F)」 を選択する

  1. 「アプリと機能」の右側の 「関連設定」 > 「プログラムと機能」 を選択する

  1. 「プログラムと機能」の左側の「Windowsの機能の有効化または無効化」を選択する

  1. 「Windowsの機能の有効化または無効化」から「SMB 1.0/CIFS ファイル共有のサポート」>「SMB 1.0/CIFS クライアント」にチェックを入れて「OK」を押す

  1. 設定後Windowsを再起動する

肩にのせるネックスピーカーを買ったが

アクティブスピーカーシステム SRS-WS1をPCのスピーカーとして購入して使ったみてがやはりPCのスピーカーとしてはイマイチだった。

SRS-WS1

それまでのPCのモニタ内蔵のスピーカーを使っていて音量も音質もあまり良くなかった。とはいえ、別売りのスピーカーの買うほどでも、ヘッドフォンをつけるほどでもないと思っていた。そんなところでこの製品を見つけて使えるのでは・・・と買った次第。

商品情報でワイヤードにも対応していたことを見つけ、最初からワイヤレスで使うつもりはなく、ステレオミニプラグで繋いで使ってみた。

  • 意外に重い
  • 首元から人の声が聞こえるのは最初は違和感がある(ずっと使っていれば慣れるはず)
  • 充電が・・・

USB接続に対応しているわけではないのでPCにワイヤードで繋いでいても当然、充電はされない。面倒くさがりの自分には数時間でバッテリーが切れてしまうのが辛かった。また充電する際に一定のスペースを専有してしまうのであれば、外付けスピーカーを並べるのと変わらなくなってしまう。

SRS-WS1

そもそもステレオミニプラグで繋いでしまうと立体的な体験も失われてしまうのかもしれない。首ではなく机の上に置いて外付けスピーカーのような使い方さえもしていた。

もともとPC向けの製品ではないし、PCで使うならUSB接続のデバイスを使った方が良いという当たり前の結論に帰結した。

Chrome 62公開前にブログをSSL化した

本ブログのSSL化対応を実施した。

今回、やったこと。

  • 自作テーマでSSL化対応
  • 過去記事の一部を更新
  • Nginxでhttpからhttpsにリダイレクト
  • WordPressの設定を変更
  • Google Analyticsの設定をhttpsに変更
  • Google Search Consoleでサイトを登録しなおし

めでたくSSL化できた。

きっかけ

Chrome 62では、httpのページで入力フォームを使おうとするとセキュアではないページとアドレスバーに表示されることになるらしい。

参考: Chrome の HTTP 接続におけるセキュリティ強化に向けて

WordPressに限らず、ほとんどのブログはサイト内検索の入力フォームを持っており、この問題に遭遇することが予測される。本ブログも例外ではないため、Chrome 62がリリースされる前に対応した次第。

前提

WordPress管理画面へのログイン時にIDとパスワードが暗号化されずに送られるのは危険なため、1年以上前からログイン画面と管理画面はSSLで表示するようにしていた。証明書は無料のLet’s Encryptを使用。そのため今回サーバ証明書のインストールなどサーバ側の基本的なSSL対応作業はNginxのリダイレクト以外しておらず、ほとんどがページ内の対応になった。

自作テーマでSSL化対応

テーマの中で外部のJavascriptやWebFontなどを利用していないかチェックした。基本的にはそれらはbowerでテーマ内にインストールし、wp_enqueue_stylewp_register_scriptで参照しているため直接外部のサーバのファイルを読んでいる箇所はほとんど無かった。唯一見つけたのがfeedlyのバッジ画像だった。その部分だけ //s3.feedly.com/img/follows/feedly-follow-rectangle-flat-big_2x.png に変更した。

プロトコルに依存しないように、プロトコル相対が勧められているので //s3.feedly.com/ で指定。

参考: サーバーでの HTTPS の有効化

過去記事の一部を更新

カメラで取った写真はFlickrにアップロードして表示している。記事内のFlickrの画像がhttpのリンクになっていためスクリプトを書いて置換した。自分はエンジニアなので独自にスクリプトを書いた方が安全だと判断したが、一括置換の代替案としては Search Regex プラグインがある。ただ正規表現というものを良く理解していない人が安易に使うのは事故のもとなので基本的には手作業で修正することをお勧めしておく。

Flickr画像以外だと、外部サイトの画像を参照する場合はリンク切れにならないようになるべく /images/ の下にコピーを置いて相対リンクで参照していた。直接外部サイトの画像を参照しているような古い記事は放置することに。古い記事だから見つけ次第、随時直せば良いと判断。

Nginxでhttpからhttpsにリダイレクト

Nginxでhttpへのアクセスをhttpsにリダイレクトするように設定した。

server {
    listen               80;
    server_name blog.makotokw.com;
    return 301 https://$host$request_uri;
}

server {
    listen               443  ssl;
    server_name blog.makotokw.com;
...

Google Search Consoleのヘルプで301リダイレクトを使えとあったのでそれに従った。

https://support.google.com/webmasters/answer/6073543
Use server-side 301 redirects
Redirect your users and search engines to the HTTPS page or resource with server-side 301 HTTP redirects.

WordPressの設定を変更

WordPressのURLの設定を変更し、Cacheプラグインを使っていたのでキャッシュをクリアした。

sitemap.xmlの作成でXML Sitemap Generatorプラグインを利用しているがWordPressのURLの設定変更によりsitemap.xml内のURLはhttpsに置き換わった。

robots.txtSitemapの箇所も https に変更。

User-agent: *
Disallow: /wp-admin/
Disallow: /wp-includes/
Allow: /wp-includes/js/
Allow: /wp-includes/css/
Disallow: /images/

Sitemap: https://blog.makotokw.com/sitemap.xml

Google Analyticsの設定をhttpsに変更

Google Analyticsの設定を変更した。プロパティとビューにそれぞれスキーマの設定がある。ただし、この設定に何の意味があるのかは理解しておらず。


Google Search Consoleでサイトを登録しなおし

Search ConsoleはURLがIDで登録になっているためhttpのものをhttpsに設定変更することはできないようだ。 https://blog.makotokw.com で再登録し、sitemap.xmlを送り直し中。ただ、ここ数年はSEOに力を入れないどころかSEOを無視すらしていたのであまり再登録に関しては気にならない。

Google AnalyticsにSearch Consoleのサイトと紐付ける設定があったのでこちらも再設定した。ちなみにこの設定で何のメリットがあるのかは理解しておらず。

まとめ

記事内の画像のURLを置き換える作業が一番、骨が折れる作業だったが、なんとかChrome 62がリリースされるまえにサイトは対応できた。今後の課題として以下のものに対応しようと思う。

  • HSTS導入
  • SSL化できていない記事の検出方法
  • 上記記事の修正

参考

MacBookに合うロジクールのワイヤレスマウスを検証した

MacBook Proで使うロジクールのワイヤレスマウスをいくつか検証して、個人的にはM545に落ち着いた。

会社で購入した新しいMacBook ProとMicrosoftのワイヤレスモバイルマウスの相性が非常に悪く、カーソルがまれに反応しなくなることがあった。実は、自宅のiMacとMicrosoftのワイヤレスマウスでも似たような問題があったので、とうとうMicrosoft製マウスを見限る決断を下した。Visual Studio CodeやOfficeなどソフトウェアはクロスプラットフォーム展開を進めているのに何故ハードウェアはこうなってしまうのか…

ロジクールは自宅のデスクトップWindows PCで使ったゲーミングマウスが良かったので(3つのゲーミングマウスを試してみた)採用。流石にラップトップで有線マウスを使うのは躊躇したため、ワイヤレスマウスを検証することにした。

今回検証したのは以下の3つ

手が小さいため、いずれも、小さめでシンプルなものを選択。

とは言えWireless Mini Mouseは流石に小さすぎたので早い段階で脱落。M545BKとM235rとではそれほど大きな違いはなかったがM545BKの方が手に馴染む感じ。最初はスムーズすぎるホイールスクロールに違和感を覚えたがいつの間にか気にならなくなった。マウスのサムボタンを使ったことがないので全く活用できていないが、ソフトウェア開発でもなにか使った方が良いだろうか。欲を言えば、カラーバリエーションで白色が欲しかった。

ALIENWARE AURORA (R5)のメモリを40GBに増強

DELLのデスクトップPCのメモリを増強し8GBから40GBにアップグレードした。

DELLのALIENWARE AURORA (R5)を使っているが、最近、Windowsが激重になり、それからタスクマネージャーを開くとメモリが枯渇している状態になっていることがある。特にメモリを潤沢に使うアプリを使っているつもりはないのだが、プロセス毎のメモリ使用量を見ても原因がわからず、見方が違うのか、メモリを解放していない輩がいるのかは不明で、もともと8GBも少ないと思ったのでメモリを衝動買い。

買ったのはこれ、どのブランドが良いかはまったくわからず。

ちなみに、もともと刺さっていた8GBのメモリのブランドはMicronだった。

Memory

これで暫くは安泰のはず。

ラブリコで壁に穴を開けずにVIVEのベースステーションを設置する

賃貸で壁に穴を開けられないのでツーバイ材とLABRICOのジョイントとアジャスター使ってHTC VIVEのベースステーションを設置してみた。

HTC VIVE Base StationHTC VIVE Base Station

前回同様、IPC DIY Lab.さんで必要な長さから半分にカットしてもらったツーバイ材と、LABRICOのジョイントとアジャスターを購入。VIVEのベースステーションは部屋の対角線上に設置することになるのでセット購入。

VIVEはドスパラWebサイトで購入。PlayStation VRがいつまでたっても定価で買えないので衝動買い。

ただ衝動で買うには設置面で問題があった。VIVEの設置動画を見ると何のためらいものなくベースステーションの設置で長いネジを壁に打ち込んでいて「どこぞのアメリカの豪邸をモデルにしてるんだよ」と賃貸住宅では敷居が高かった。

そんな中、ディアウォールで自転車やらギターやらを掛けているDIY写真などを見て、VRのベースステーションもこれでいける…と判断できた。

モノの配置によっては、部屋の角にツーバイ材を設置するのは面倒になるかもしれなかったが、半分にカットしている場合は部屋の角でジョイントすることでこれまた簡単にできた。ジョイントをつかったラブリコの万能さに今後も頼ってしまいそうである。

Apple WatchでGoogleカレンダーの予定を見るアプリ

Apple WatchでGoogleカレンダーの予定が見れるアプリとして Tiny Calendar を使い始めることにした。

iOSのAndroidと比べた場合の数少ない不満としてOSデフォルトのカレンダーとGoogleカレンダーと連携が貧弱なところだ。仕方がないのでこれまではサードパーティ製のCalendars by ReaddleというGoogleカレンダーの予定を同期して、Googleカレンダーの予定を見やすく表示してくれるアプリを使っていた。

このアプリは時々同期が行われない以外は気に入っていたのだが、Apple Watchアプリに対応していないため、Apple Watch上でGoogleカレンダーの予定を表示できるアプリを探し、 Tiny Calendar を使うことにした。

Apple Watchで予定が見れるようになって便利になったが、いくつか問題も見つかっている。Apple Watchのアプリが通信しているのはiOS側のTiny Calendarアプリであるため、まずiOS側でTiny Calendarを起動して予定を同期しておかないといけないというところである。つまり、朝起きてApple Watchで予定を確認しようと思うと、まずiPhoneでTiny Calendarを起動して最新の予定を同期しておかないといけないので「いやその時点でiPhoneで予定見るわ」となってしまう…

予定が増えていないのであればこの「まずiPhone側のTiny Calendarの予定を同期する」手順は必要ないとも言えるが、予定を忘れないためにアプリに頼っているわけなので昨日から予定が増えていないかどうかを記憶や予測に頼るわけにはいかない。

もう一つ、以前から感じていた問題で開始5分前の通知が来る予定と来ない予定があるところ。いろいろ試してみたがGoogleカレンダーのデフォルトの通知設定がモバイルには効いてないように見える。Googleカレンダーのヘルプにはデスクトップとモバイルで通知設定は共通のように書いてあるのだが、新規に予定を追加してデスクトップPCのブラウザで予定を見ると5分前の通知が設定されているが、モバイルのGoogleカレンダーアプリで見るととリマインダ通知が設定されていないのである。

基本的に予定はデスクトップPCから追加していることが多いが、それからモバイルのGoogleカレンダーアプリでリマインダの通知を追加すると通知が来るようになった気がする。

Apple Watchの通知も結局はiPhoneアプリ上の通知なのでこちらも、iPhoneでTiny Calendarを起動して通知設定を含めて予定を同期しておかないといけない。というわけで少し前準備設定が面倒だが、会議やら個人的なTODOをスケジュールにいれておくとApple Watchが通知してくれるので記憶に頼りたくない自分はその準備をするだけの価値は十分になると思う。

Raspberry PiのLANがとんだ

自宅サーバとして使っていたRaspberry PiのLANが止まってしまったのでSDカードだけ付け替えて復旧した。

外からサーバに接続できなかったので最初はハングしているのかと思ったけど、電源を入れ直して再起動しても接続できず。ディスプレイを繋ぐとちゃんとOSは起動しており、ネットワークがつながっていない状態であることがわかった。それからLANケーブルを繋ぎ直したり、別のLANケーブルに交換してみてもつながらないのでRaspberry PiのLANポートがお亡くなりになったと判断。

自宅サーバで使っていたRaspberry PiはB+で、このタイミングではModel 2やModel 3に置き換えることも考えたが特にModel B+で困っていることもなく、また1からセットアップしてデータを移行するのも面倒なので、バックアップ用に取っておいた新品のRaspberry Pi B+に壊れたRaspberry PiのSDカードを指したら普通に稼働再開できた。

Raspberry Piは製造している会社によって微妙に違うのでもしかしたら別のRasbperry PiのSDカードでもダメなケースがあるかもしれないが、今回は両方ともRSコンポーネンツ製だった。こんな簡単に故障から復旧できるのは素晴らしいが、逆にSDカードが死んだらこの方法は使えないので、SDカードを選ぶ際はあまり妥協しないほうが良いと思った。

3つのゲーミングマウスを試してみた

デスクトップPCをWindows 10にしてからMicrosoftのモバイルマウスの反応が悪く、やはり有線の方がよいかな…と思っているうちに何故かゲーミングマウスを購入していた。ゲーミングマウスのレスポンスが必要な作業をしているわけではないのだが、妥協して失敗するくらないなら良いのを買ってしまえと、注文してしまった。

G PRORazerEC2-A

購入したのは以下の3つ。

前提として手が小さく(それ故、マイクロソフト モバイルマウスを使っていた)、事前に手の小さい人でも使えそうかという視点で調べたところ、この3つが候補になった。自分の主観の持ちやすさのみで評価したところ ロジクール Pro Gaming Mouse が一番持ちやすかった。マウスについてはいろいろなレビューがあるが、結局のところ自分の手で握って試すしかないので店頭で触るか、無駄になってもいいから思い切って買うのが良いと思う。(ただゲーミングマウスのいろんな色で光る機能は要らない…)

というわけで、ロジクール Pro Gaming Mouseが一番良かったという個人的見解は他の人には役に立たないことがあります。特にゲームで試したわけではないのでゲーム用マウスを探している人には参考になりません。