当社はIT技術のオンライン教育を得意としたセミナー専門会社です。

ITエンジニアの技術力UPをお約束します。

Windows Update後にInkscapeの新規追加フォントが認識されない問題を解決する。

Windows Update後にInkscapeの新規追加フォントが認識されない問題を解決する。


私がよく使うグラフィックソフトは幾つかあるが、最も使用しているのがInkscapeです。ベクターで使えるグラフィックソフトはイラストレータ以外というとこれが一番使い勝手が良い。フリーだしね。このInkscapeですがWindows Updateのあるバージョンから新規で追加したフォントが認識されない問題が発生している。ネット上の質問でもワールドワイドでこの問題に遭遇しているのがわかる。日本でも旧Updateバージョンに戻して回避したなどの報告がある。結論言ってしまうとこの原因はWinodws10がユーザ毎の所有するフォントディレクトリに仕様変更(パス変更)が生じたために起きている問題なのですよ。Linuxのようにユーザ毎に~/.fontsに相当することをWindows10がやったということなんでしょうね。

解決方法

解決はすごく簡単です。新規追加フォントをダウンロードしたら圧縮を展開して、ファイル名の上でマウス右クリックから「すべてのユーザに対してインストール」を実行するだけです。下記を参考にしてください。 つまりこの選択メニューで導入すると旧来のWindows全体で共通のFontフォルダーを参照するため追加したFontが参照されるわけです。今は直接C:\Windows\Fontsにドラッグ&ドロップしても無駄です。前述の操作をしないとInkscapeは認識しません。

タグ: , ,

SSL証明書 無料の Let’sEncryptの発行トラブルを解決する。


無償のSSL証明書発行で有名なLetsEncryptですが、うまく発行されない場合が多かったりします。最初の登録で3ヶ月後の更新を忘れたり、既に有償のSSLを使っていて期限を過ぎて更新しないと行けない。サーバ移転のときはどうするの?

長く使っていると概ねこのような問題に遭遇します。今回はLetsEncryptを発行するときのツボを解説したいと思います。

LetsEncryptには2種類の登録モードがある。

2種類のモード
  • ・スタンドアロン モード
  • ・WEBルート モード

スタンドアロン モード

WEBルート モード

この2つのモードの違いですが、スタンドアロンモードはWEBサーバの停止が必要です。一方WEBルート モードはWEBサーバの停止が必要ありません。

初心者にありがちなミス

  • Linuxサーバの443、80ポートをオープンしていない。iptablesやfirewalldでポートをオープンしましょう。
  • DNSサーバに事前に発行ドメインのIPアドレス登録が抜けている。LetsEncrypt発行前にかならずDNS登録を行いましょう。

既に有償のSSLライセンスが切れてLetsEncryptを使いたい場合

WEBサーバ停止することなく、「WEBルート モード」で発行が出来ます。もし失敗するようであればWEBサーバ停止してスタンドアロンモードで試してみてください。念の為、初心者の方には言っておきますがどちらのモードもSSL証明書の登録・更新設定をしたら再起動をお忘れなく。

初回の登録からの期限忘れで手動及び自動更新が失敗。

このケースでは、基本スタンドアロン モードでの新規登録となります。ただ単純にスタンドアロンモードで登録しても失敗することでしょう。以下のファイルを削除してください。

  • # rm -rf /etc/letsencrypt/live/www.test-serv.net
  • # rm -rf /etc/letsencrypt/archive/www.test-serv.net

以上の作業が終わったら、再度新規発行してみてください。大概はうまくいくはずです。必ずWEBサーバを止めて、スタンドアロンモードで発行してください。

LetsEncryptを使用していましたが、サーバ移転で別のホスティングへ移したら登録できない。

/etc/letsencryptファイルを固めて新サーバへ持ってくれば、有効期限に達するまではすんなり使えます。問題は期限が来た時に起きます。この場合も更新ではなくて新規登録が必要。上記のSSL期限忘れと同じ要領の作業を行ってください。必ずサーバ移転先のIPアドレスにドメインが変更されていることを確認してから発行してください

既にDNS CAAレコードを設置している場合で、新規発行が失敗する。

以前使用していた有償などのCAAレコードとLetsEncryptのIssuer(発行者)が異なるため失敗している可能性があります。この場合はCAAレコードのissueをletsencrypt.orgに変更すると登録が出来ます。

タグ: , , ,

XXXXPayサービスのスマホ引っ越し注意点


世の中にxxxxPayのサービス増えましたね!私も片っ端から試してみましたが、ちょっと使いかってが。。。。。ですね。傍から見てもレジのところで躊躇している、操作に迷っているケースの人が多く、いわゆるSUICAのような交通系のカード(Suica)やIDカードのようなタッチ系のほうが良い感じがします。スマホはネットの接続状態、輝度、画面表示操作が関係してくるため実は面倒くさいし、手こずっている人が大勢いる。

さて、本題ですが私は幾つかのxxxxPayを使って一番失敗したなーと思うのはスマホを変えたときです。実はxxxxPayって電話番号と紐付いているんです。スマホを変えた時に電話番号が変わらなければ初期のセットアップだけで移行できたはずなのですが、最初に契約した際の電話番号を解約してしまったために、とんでもないことに!!そう!電話番号を変えると使えなくなってしまうのですよ。これをリカバリーするのはすごい大変なことで、最近のネットサービスは受付電話がない!!!全てメールやWEBフォームからの依頼になります。すごい厄介ですね。そう連絡しても反応が無い。。。恐らく、スマホを引っ越しする時は各XXXXPayのメニューには引っ越し用の申請メニューがあるのではないかと思います。スマホを買い直す時は必ず調べておきましょうね。

アカウントリカバリーのベストウェイ

リカバリーのベストウェイは2パターンあります。一つ目は再度アカウントを作る。こうしないとだめなxxxxPayもありました。2つ目はチャットです。チャットが使えるケースではこれが一番はやくて確実でした。結構待たされたけど、まあ、出てくれればあとの対応はスピーディです。Lineさんは特にLineアカウントに「Line Payお問い合わせ」専用アカウントが存在しここでチャットで対応してくれました。フォームは全く無視されてましたがチャットでは対応する方が10分位で出てくれたので良かった!

タグ: , , , , ,

備忘録:cakephp2.xでSSL化した場合のトラブル「The request has been black-holed」の対処


今年は7月からGoogle Chromeブラウザの非httpsなサイトをSSL化するための仕事で大忙し。 よくある問題は何かと言うと、表題の「The request has been black-holed」がcakephpで作られた環境でSSL化すると頻発するアクシデントに見舞われる。 この問題はよくある既知の問題なのでネット上にも対処方法はそこそこ見つけることができる。


しかし、人それぞれ、独特の作りかたをしているため、他人のソースコードを読み取って適材適所にコードを埋め込んだり修正するのは大変。 もう、cakephp絡みで今月に入ってから5件の案件で遭遇した。短い時間で修正すべきソースコードとその箇所を見つけるのはなかなかしんどい。

ということで、また遭遇するだろうからメモを残しておく。

対象Controllerを修正する

概ね以下のようなコードを挿入する。システムの作り方によるが修正箇所は大抵「app/Controller/」「app/Plugin/Admin」の下にあるメインコントローラか、機能単位のコントローラに入れることになるだろう。

cakephpのSSL化でインターナルサーバエラーの場合の回避策の一つapp/Config/core.phpの編集でエラーレベルを抑制

php.iniで既にエラーレベルが「E_ALL & ~E_DEPRECATED & ~E_STRICT」に設定されてれば問題ないが、サーバ上にある特定のアプリのみ制御するならcakephpであれば下記を修正します。

タグ: , , , , ,

https化で出てくる問題(https化した途端にmod_rewriteが効かなくなってしまう)


Google Chromeの7月リリースバージョンでいよいよサイトのALL SSL化が始まる。
これによりhttpに対応していないサイトは「このサイトは安全でない」の画面が出てしまう。今でも
稀に見ることがある画面ですが、あの画面がでてしまったら当然誰もクリックor タップしないでしょう 。

ということでSSL化をしなければ行けないわけだけど、もう一つこれには考慮が必要なことに気づいた。
スマホとPCコンテンツを分離して作成している場合はアノテーション設定が必要だが、モバイルファーストインデックスも
開始宣言(2/21)が出ているし、何よりもアノテーション設定でURLをhttpsに変更しなければならない。

※レスポンシブで制作している場合は気にする必要はありません。WORDPRESSでデバイスプラグインを使っている人も問題なし

ということでSSL化をやってみると色々な新規顧客である特有の問題が出た。
一番ハマったのが、「https化した途端にmod_rewriteが効かなくなってしまう。httpのときにはmod_rewrite使えたのに!」という現象のサーバが幾つかあった。
つまりWORDPRESSなどではカスタムパーマリンクが使えなくなってしまう現象に遭遇しました。

原因を調べるために、約1日考え込み実験をしまくりました。
や~、これは気が付かなかった。httpd.confを普段触らずVirtualHostでサイト定義するから頭がそちらに向かなかった。
なんとhttpd.confを調べたら下記のようになっているではないですか! なるほど、それではTOPからその設定になっていると
下位で設定したコンフィグは無視されますね!

httpd.conf 修正前)

httpd.conf CentOSの場合修正後)

apache2.conf Ubuntuの場合修正後)



apacheを再起動してめでたくmod_rewriteがSSLで使えるようになりました。
上記の設定はDirectoryディレクティブを使用しているため、適切に範囲設定をその環境内で
望ましい設定を厳密には行う必要があります。上記のケースでは”/”でAllowOverride Allにしているためセキュリティを
高くするためにはフォルダーの範囲をもう少し狭めたほうが良い場合もあるので実験して良いバランスの設定を考慮スべきと思います。

他にも、https化で出てくる作業が多いのでメモをしておきます。

https化で遭遇する付帯作業

  • Google Search Consoleにhttpsでサイト登録が必要
  • 旧httpアドレスがインデックスされたり、他サイトと連携している場合はhttpアドレスからhttps転送設定が必要
  • 転送設定をjavascriptでやる場合は注意が必要。コンバージョンが拾えなくなる可能性がある。リファラーを追加する設定が必要かも
  • Google Analysticsの管理画面でプロパティ、ビューのURLをhttpsに切り替える。ビューのコンバージョンURLも変更。
  • sitemap.xmlをhttpsのアドレスになっているかチェック、なっていなかったら作り直し
  • WORDPRESSのプラグイン経由でanalysticsを設定、取得している場合は再設定が必要になる場合が多い

タグ: , , , ,