memo.

カテゴリー: 技術系

  • 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' );

    参考： https://qiita.com/katzueno/items/ec4cb5997eb8a066fefc

  • Windows10のhostsファイル

    Windows10のhostsファイルが保存されているフォルダは下記。

    C:\Windows\System32\drivers\etc\
hosts

    Windows10になっても、hostsを編集するとは思わなかった。忘れていたので、メモを残す。

  • SurfacePro6を初期化すると初期化前の大型アップデートのバージョンになる

    Surfapce Pro 6は、Windows10の大型アップデート（May 2019 Update)を適用すると、初期化時も大型アップデート後のバージョンになる。

    Cドライブの下の「Windows.old」フォルダは残るが中身は空。

  • 古いAD環境下でのWindows Helloの設定

    AD環境下の場合、「設定」→「アカウント」→「サインイン オプション」のWindows Helloの設定部分がグレーアウトしており、設定できない。

    古いActive Directory（機能レベルがWindows 2000やWindows 2003）のときに、ADのグループポリシーを使用せずに、Windows 10で、Windows Helloが使えるようにする設定の手順。

    手順

    1. 「Windowsキー」を押し、「gpedeit.msc」を入力し、「グループポリシーの編集」を選択して、起動する。
    2. 「ローカルグループポリシーエディター」が開く
    3. [コンピューターの構成] > [管理用テンプレート] > [システム] > [ログオン] の順に選択する
    4. 「便利なPINを使用したサインインをオンにする」の項目を選択し、右クリックから「編集」を選択する。
    5. 「有効」を選択する。
    6. 「適用」ボタンをクリックする。
    7. 「OK」ボタンをクリックする。
    8. 「ローカルグループポリシーエディター」を閉じる。
    9. コマンドプロンプトを管理者として実行する。
    10. コマンド“gpupdate /force” を実行し、強制的にグループポリシーをPCに反映させる。この時、ADと通信できない環境で行うとグループポリシーの適用に失敗する。
    11. PCを再起動する。
    12. 「Windowsキー」を押し、設定（歯車マーク）を開く。
    13. 「アカウント」を選択する。
    14. 「サインイン オプション」を選択する。
    15. Windows Helloの部分が選択できるようになっていれば、成功。グレーアウトのときは、グループポリシーの適用がうまくいっていないので、もう一度、設定する。
    16. Windows Helloの設定を行う。PINの設定も求められるので、行う。

    いろいろと試してわかったが、AD環境下であってもローカルのグループぽしりーであれば「Windows Hello for Business」は関係ない。「for Business」の設定はやらない。やると、よくわからない状態になる。

    Windows Helloの設定にBitLockerによる暗号化の有無は関係ない。

  • pythonのコーディングは、標準コーディング規約のPEP8をベースにして、つくる。

    pythonのコーディングは、標準コーディング規約のPEP8をベースにして、つくる。

    https://pep8-ja.readthedocs.io/ja/latest/

    大して、長くなく、基本的なことだけなので、読みやすく、守りやすい。

    コーディング規約の「コメント」についての規約の部分に、「英語を書くときは、Strunk and White スタイルを使いましょう」 とある。知らなかったが、ストランクとホワイトによるコンパクトな英文の作成スタイルのことらしい。Kindleで格安で売っているので、読んでみてもいいかも（読めるかどうかは不明だが）。レビューによると、2章が胆のようだ。

    https://amzn.to/2WPfZ5x

  • Powershell起動時に「～PowerShell をお試しください」が表示される

    PowerShellを起動させたところ、下記のメッセージが表示された。

    Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.

新しいクロスプラットフォームの PowerShell をお試しください https://aka.ms/pscore6

PS C:\Users\zen>

    この表示されたURLにアクセスすると、Powershell6のページになる。

    つまり、Powershell6（正確には、Powershell Core 6）のインストールを促すメッセージ。既存環境のPowershellのバージョンを確認すると、Powershell 5.1なので、6をお勧めしてきているようだ。

    PS C:\Users\zen> $PSVersionTable

Name Value
---- -----
PSVersion 5.1.18362.145
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.18362.145
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1

PS C:\Users\zen>