SQLiteは、INSERT、DELETEが多い場合、DBの断片化が多くなる。自動では、断片化した後の不要領域を解放しないため、定期なVACUUMコマンドの実行が必要。VACUUMによって不要領域のメンテナンスをしないと、性能に影響がでる。
カテゴリー: 技術系
-
Acronis 12.5のデフォルトDBはSQLite
Acronis 12.5をインストールしたときに、バックアップ情報を保存する先のDBは、SQLite。ファイルサイズに上限はないが、サイズが増えれば増えるほど、性能には難あり。
Acronis12.5は、バックアップの情報がよく管理サーバ上で記録されていなかったりする。バックアップのタスクが増えれば増えるほど、不安定なことがあるので、SQLiteがボトルネックになっている可能性が高い。大規模導入なら、他DBMSを選んだほうがよい。
-
VSCodeのCisco用のコマンドモード
Visual Studio CodeにCiscoのシンタックスを解釈できるようにするExtension。下記のエクステンションのページからインストールボタンを押して、インストールする。
vscode-cisco-syntax
https://marketplace.visualstudio.com/items?itemName=jamiewoodio.ciscoインストール後は、言語モードの選択で「cisco」と指定する。そうすると、Ciscoのシンタックスで色付けなどをしてくれる。
コンフィグをみるときのサポートくらいに使える。コンフィグに対して、完全には、色がつかないが、ある程度つくだけでも、可読性はあがる。コンソールの作業履歴もモード指定すれば、シンタックスで色をつけてくれるのでよい。
-
BCDMのAndroid Enterpriseのアプリページは１つにつき、100アプリまで
ソフトバンクのMDMのBCDMのAndroid Enterpriseのアプリページは１つにつき、100アプリまで。
100アプリしか登録できないので、カテゴリを「その他」みたいな形で作って、全てを入れることができない。また、複数ページに同じアプリを登録できる（重複できる）ので、いちいち探すのが大変。
-
Ubuntu タイムゾーンの設定
Ubuntuでタイムゾーンの設定をCLIで変更するときの手順。GUIが使えるのならば、GUIでやった方が楽。
まずは、timedatectlコマンドで現在のタイムゾーンがどこなのかを確認する。
~$ timedatectl Local time: Tue 2019-06-25 06:01:14 UTC Universal time: Tue 2019-06-25 06:01:14 UTC RTC time: Tue 2019-06-25 06:01:15 Time zone: Etc/UTC (UTC, +0000) System clock synchronized: yes systemd-timesyncd.service active: yes RTC in local TZ: no次に、”timedatectl list-timezones”で、タイムゾーンを表示させ、中から選ぶ。量が多いので、grepなどを使ってある程度絞り込むとよい。
次に、”timedatectl set-timezone タイムゾーン” で、変更後タイムゾーンを変更する。成功したかどうかの反応はないため、実行後に設定を確認する。
~$ sudo timedatectl set-timezone America/Los_Angeles ~$ ~$ timedatectl Local time: Mon 2019-06-24 23:02:41 PDT Universal time: Tue 2019-06-25 06:02:41 UTC RTC time: Tue 2019-06-25 06:02:42 Time zone: America/Los_Angeles (PDT, -0700) System clock synchronized: yes systemd-timesyncd.service active: yes RTC in local TZ: no ~$設定例（sudoを付けずに実行しているため、途中で失敗もしている）
ubuntu@ip-10-0-0-122:~$ ubuntu@ip-10-0-0-122:~$ timedatectl list-timezones | grep -i america/Los America/Los_Angeles ubuntu@ip-10-0-0-122:~$ ubuntu@ip-10-0-0-122:~$ ubuntu@ip-10-0-0-122:~$ ubuntu@ip-10-0-0-122:~$ timedatectl Local time: Tue 2019-06-25 06:01:14 UTC Universal time: Tue 2019-06-25 06:01:14 UTC RTC time: Tue 2019-06-25 06:01:15 Time zone: Etc/UTC (UTC, +0000) System clock synchronized: yes systemd-timesyncd.service active: yes RTC in local TZ: no ubuntu@ip-10-0-0-122:~$ ubuntu@ip-10-0-0-122:~$ ubuntu@ip-10-0-0-122:~$ timedatectl list-timezones | grep -i america/Los America/Los_Angeles ubuntu@ip-10-0-0-122:~$ ubuntu@ip-10-0-0-122:~$ timedatectl set-timezone America/Los_Angeles ==== AUTHENTICATING FOR org.freedesktop.timedate1.set-timezone === Authentication is required to set the system timezone. Authenticating as: Ubuntu (ubuntu) Password: polkit-agent-helper-1: pam_authenticate failed: Authentication failure ==== AUTHENTICATION FAILED === Failed to set time zone: Access denied ubuntu@ip-10-0-0-122:~$ sudo timedatectl set-timezone America/Los_Angeles ubuntu@ip-10-0-0-122:~$ ubuntu@ip-10-0-0-122:~$ timedatectl Local time: Mon 2019-06-24 23:02:41 PDT Universal time: Tue 2019-06-25 06:02:41 UTC RTC time: Tue 2019-06-25 06:02:42 Time zone: America/Los_Angeles (PDT, -0700) System clock synchronized: yes systemd-timesyncd.service active: yes RTC in local TZ: no ubuntu@ip-10-0-0-122:~$ -
バーチャルホストで404ページの指定をする方法
Apache24のバーチャルホストで、独自の404エラーのページを設定する方法。”.htaccess”でもできるが、サイトを閉鎖するときに適用したかったので、”VirtualHost”の設定としておこなった。
バーチャルホストの設定の中にErrorDocumentの設定を書く。このとき、エラーページのHTMLファイルは、絶対パスで書く。（絶対URLで書いてはいけない。相対パスでも書いてはいけない。）
ErrorDocument エラーコード エラーページのHTMLファイル（絶対パスで書く）
設定例。
DocumentRoot /var/www/blog ServerName xxxx.xenos.jp ErrorDocument 404 /404.html ※404以外のエラーも表示させるので、あれば、それぞれエラーコードと対応するエラーページを保存し、指定すればよい。
-
NginxでWordPressのパーマリンクが動かず、Apacheに変えた
WordPress用のサーバ構築があったので、フロントのウェブサーバをNginxで設定した。PHPの動作や、Wordpressの初期設定までは、問題なし。Wordpressのパーマリンク設定をデフォルトから、変更したところ、404エラーに。Nginxなので、「.htaccess」でのrewrite設定が効かないので、Nginxの設定を変えて対応していが、いろいろと試しても動かない。いつまでも時間をかけてられないので、パーマリンクの問題で、Apache2.4系に変更した。Apache2.4だと、かなりあっさりと動作した。
どこか時間を見つけて、Nginx ＋ PHP ＋ WordPressのパーマリンクの設定を検証しなくては。公式サイトの手順でもダメだったから、なんでだろう。たぶん、途中の設定とかがよくないのだろうな。やり直したら、さくっと動作するとか、そういうパターンだろう。
-
ELB+ACMでSSL通信を行うときのメリット・デメリット
AWSで、SSL通信を行う設定をすることになったので、ELB（Elastic Load Balancer）＋ACM（Amazon Certificate Manager）でSSLを通信を行うときのメリット・デメリットを考えてみた。癖はあったけれど、驚くほど設定が簡単。
デメリット
- ELBのコストがかかる、ELBは従量課金
- ELB経由で、アクセスするためには、ELBのアドレスをCNAMEで指定する必要がある（ELBのIPアドレスは変動するから）
- ELBでSSL通信がオフロードされるので、アプリケーション側の対応が必要（Wordpressだと、追加設定必要だった）
メリット
- ELBがSSL通信の終端になる
- ELBがSSLのオフロードをしてくれるので、EC2側のSSL設定はいらない
- EC2にSSL設定をしないので、OpenSSLの脆弱性と闘わなくていい（アップデートの手間が軽減される）
- Amazon発行のSSL証明書が無料で使える（ELBにはコストがかかる）
- ELBを使用するので、スケールアウトが用意になる
- 証明書の設定が簡単にできる（認証キーとかの知識もいらないので楽ちん）
-
AWSのELBでWordPressを使うと”ERR_TOO_MANY_REDIRECTS”がでる
AWSで、WordpressとSSLを使うためにELB（Elastic Load Balancer）を設定したのだが、アクセスすると、”ERR_TOO_MANY_REDIRECTS” が表示される。
調べてみると、Wordpress＋SSL＋ELBの組み合わせで発生しているとのこと。Amazonの公式ページの内容も試してみたが、効果なし。
https://aws.amazon.com/jp/premiumsupport/knowledge-center/redirect-http-https-elb/
Nginxを使ったので、その設定を試したが効果なし。
WordPressの設定で回避できることがわかったので、その設定を実施。
“wp-config.php” の「wp-settings.php」の読み込み前に設定を追加。これで、アクセスしたところ、見事に成功。このとき、Nginxの設定は元に戻した状態で実施しても問題なかったので、Nginxの設定ではなく、Wordpress側の設定で回避できる問題だったようだ。
/** Absolute path to the WordPress directory. */ if ( ! defined( 'ABSPATH' ) ) { define( 'ABSPATH', dirname( __FILE__ ) . '/' ); } /** 追加した設定 **/ if ($_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https') { $_SERVER['HTTPS'] = 'on'; $_ENV['HTTPS'] = 'on'; } /** Sets up WordPress vars and included files. */ require_once( ABSPATH . 'wp-settings.php' ); -
Windows10のhostsファイル
Windows10のhostsファイルが保存されているフォルダは下記。
C:\Windows\System32\drivers\etc\ hosts
Windows10になっても、hostsを編集するとは思わなかった。忘れていたので、メモを残す。