VScodeのMarkdownでも、コメントアウトの記述ができた。
プレビューおよび、Markdown:PDFでも、コメントアウトされた記述については、表示されないことを確認。Markdownのコメントアウトは、HTMLと同じ方法で可能(下記を参照)。
VScodeのMarkdownでも、コメントアウトの記述ができた。
プレビューおよび、Markdown:PDFでも、コメントアウトされた記述については、表示されないことを確認。Markdownのコメントアウトは、HTMLと同じ方法で可能(下記を参照)。
SQLiteは、INSERT、DELETEが多い場合、DBの断片化が多くなる。自動では、断片化した後の不要領域を解放しないため、定期なVACUUMコマンドの実行が必要。VACUUMによって不要領域のメンテナンスをしないと、性能に影響がでる。
Acronis 12.5をインストールしたときに、バックアップ情報を保存する先のDBは、SQLite。ファイルサイズに上限はないが、サイズが増えれば増えるほど、性能には難あり。
Acronis12.5は、バックアップの情報がよく管理サーバ上で記録されていなかったりする。バックアップのタスクが増えれば増えるほど、不安定なことがあるので、SQLiteがボトルネックになっている可能性が高い。大規模導入なら、他DBMSを選んだほうがよい。
Visual Studio CodeにCiscoのシンタックスを解釈できるようにするExtension。下記のエクステンションのページからインストールボタンを押して、インストールする。
vscode-cisco-syntax
https://marketplace.visualstudio.com/items?itemName=jamiewoodio.cisco
インストール後は、言語モードの選択で「cisco」と指定する。そうすると、Ciscoのシンタックスで色付けなどをしてくれる。
コンフィグをみるときのサポートくらいに使える。コンフィグに対して、完全には、色がつかないが、ある程度つくだけでも、可読性はあがる。コンソールの作業履歴もモード指定すれば、シンタックスで色をつけてくれるのでよい。
ソフトバンクのMDMのBCDMのAndroid Enterpriseのアプリページは1つにつき、100アプリまで。
100アプリしか登録できないので、カテゴリを「その他」みたいな形で作って、全てを入れることができない。また、複数ページに同じアプリを登録できる(重複できる)ので、いちいち探すのが大変。
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:~$
Apache24のバーチャルホストで、独自の404エラーのページを設定する方法。”.htaccess”でもできるが、サイトを閉鎖するときに適用したかったので、”VirtualHost”の設定としておこなった。
バーチャルホストの設定の中にErrorDocumentの設定を書く。このとき、エラーページのHTMLファイルは、絶対パスで書く。(絶対URLで書いてはいけない。相対パスでも書いてはいけない。)
ErrorDocument エラーコード エラーページのHTMLファイル(絶対パスで書く)
設定例。
DocumentRoot /var/www/blog ServerName xxxx.xenos.jp ErrorDocument 404 /404.html
※404以外のエラーも表示させるので、あれば、それぞれエラーコードと対応するエラーページを保存し、指定すればよい。
WordPress用のサーバ構築があったので、フロントのウェブサーバをNginxで設定した。PHPの動作や、Wordpressの初期設定までは、問題なし。Wordpressのパーマリンク設定をデフォルトから、変更したところ、404エラーに。Nginxなので、「.htaccess」でのrewrite設定が効かないので、Nginxの設定を変えて対応していが、いろいろと試しても動かない。いつまでも時間をかけてられないので、パーマリンクの問題で、Apache2.4系に変更した。Apache2.4だと、かなりあっさりと動作した。
どこか時間を見つけて、Nginx + PHP + WordPressのパーマリンクの設定を検証しなくては。公式サイトの手順でもダメだったから、なんでだろう。たぶん、途中の設定とかがよくないのだろうな。やり直したら、さくっと動作するとか、そういうパターンだろう。
AWSで、SSL通信を行う設定をすることになったので、ELB(Elastic Load Balancer)+ACM(Amazon Certificate Manager)でSSLを通信を行うときのメリット・デメリットを考えてみた。癖はあったけれど、驚くほど設定が簡単。
デメリット
メリット
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' );