Google Analytics 手動でサイトを追加する覚書

手動で Google Analytics のコードを、ホームページに貼り付けてGoogle Analyticsを動作するようにします。最低限の手順・動作確認方法の覚書を作りました。

手っ取り早く、とりあえず、サイトをGoogle Analytics に登録したい時のための覚書です。

WordPressを利用している場合は、Google Site Kitを利用するのが最も手っ取り早いです。この手順は、通常のHTMLにGoogle Analytics からタグを取得し、それを該当のページに貼り付けて、Google Analyticsに登録する方法です。

手動でプロパティを作成

最近WordPress でGoogle Site Kitばかり使っていたので、手動でコードを追加するのを忘れちゃって。それにインターフェースも変わっているからどこに何があるやらで。

手動でホームページにコードを追加するための覚書です。左下の歯車のマーク、設定をクリックする。

プロパティを作成

今回は、プロパティから作成しました。アカウントからあたらしいものを作成してもOK

データストリームをクリック

右の閉じた大なり記号をクリック

タグ設定手順 → 新しいページ上のタグを追加する → グローバルサイトタグ の中に、タグが表示されるので、このJAVA Scriptを該当のホームページ<head>タグ内に貼り付けます。

動作確認

レポート → リアルタイム を確認します。

該当サイトにアクセスした際に、ユーザ数が表示されれば動作してます。

zoom 分科会 ブレークアウトルームのやり方

情報ソースはこちら

ブレークアウトルームを有効にする

ブレークアウトルームを利用するためには、アカウント設定で、ブレークアウトルームをオンにしないといけません。

この操作は、アカウント設定を編集する特権のある管理者が行う必要があります。

ミーティングタブの中なのブレイクアウトルームを有効にします。

自分のアカウントの設定

上記設定をしておくと、自分が利用するアカウントにもブレイクアウトルームが出てきます。

こちらも有効にします。

作成したミーティング上のオプションにも、ブレイクアウトルーム事前割り当てなど、項目が表示されるようになります。

この状態で会議に入ると、ツールの中にブレイクアウトルームが表示されました

ブレイクルームアウトルームのオプション

  • 参加者にルームを選択させる:参加者は自分でルームを選択し、入室できます。
  • 自動: Zoom が参加者を各ルームに参加者を平等に割り当てます。
  • 手動: 各ルームに割り当てる参加者を選択します。

.net C#で、SSH接続できるようにする

SSH.NETって何?

SSH.NETは、並列処理用に最適化された.NET用のセキュアシェル(SSH-2)ライブラリ

同期方式と非同期方式の両方を使用したSSHコマンドの実行が可能で、コマンド実行終了ステータスやそのほかの情報を取得する事ができます。

nugetで簡単に取得できる

nuget: コード共有する仕組み

SSHを検索するとSSH.NETが見つかる

SSH.NET is a Secure Shell (SSH) library for .NET, optimized for parallelism and with broad framework support.

コード生成

とりあえずボタンを一つ生成する

そのボタンの中のコードはこんな感じ

参照

この時、

using Renci.SshNet;

しておく

        private void SSH_Click(object sender, EventArgs e)
        {
            var connectionInfo = new ConnectionInfo("sftp.foo.com",
                                        "guest",
                                        new PasswordAuthenticationMethod("guest", "pwd"),
                                        new PrivateKeyAuthenticationMethod("rsa.key"));
            using (var client = new SftpClient(connectionInfo))
            {
                client.Connect();
            }
        }

接続ボタンを押すと、サーバ側で、接続ログが確認できた

Jun 16 10:22:24 ssh-bullseye sshd[1317]: Accepted password for guest from 192.168.0.100 port 55783 ssh2
Jun 16 10:22:24 ssh-bullseye sshd[1317]: pam_unix(sshd:session): session opened for user guest(uid=1000) by (uid=0)
Jun 16 10:22:24 ssh-bullseye systemd-logind[397]: New session 36 of user guest.
Jun 16 10:22:24 ssh-bullseye sshd[1323]: Received disconnect from 192.168.0.100 port 55783:11: Connection terminated by the client.
Jun 16 10:22:24 ssh-bullseye sshd[1323]: Disconnected from user guest 192.168.0.100 port 55783
Jun 16 10:22:24 ssh-bullseye sshd[1317]: pam_unix(sshd:session): session closed for user guest

作成されたフォルダの中身

こんな感じでできてる。

実は、昔作成したアプリケーションは、このdllを流用して作成してた。nugetしてない。

古いDLLを削除してnuget

古いDLLは削除して、nugetで最新の安定板を取得する

これで、最新版の

Renci.SshNet

がインストールされた

無事に起動した。

最新サーバにアクセスしてみると接続できた!

Jun 16 10:34:58 ssh-bullseye sshd[1331]: Accepted password for DESKTOP-GT from 172.21.100.15 port 55876 ssh2
Jun 16 10:34:58 ssh-bullseye sshd[1331]: pam_unix(sshd:session): session opened for user DESKTOP-GT(uid=1385) by (uid=0)
Jun 16 10:34:58 ssh-bullseye systemd-logind[397]: New session 37 of user DESKTOP-GT.
Jun 16 10:34:58 ssh-bullseye systemd: pam_unix(systemd-user:session): session opened for user DESKTOP-GT(uid=1385) by (uid=0)

ssh_dispatch_run_fatal DH GEX group out of range 問題継続中

サーバを更新しようとしたらOpenSSHのバージョンが上がってた

Debian11にアップグレードしたら、OpenSSHのバージョンが上がっており、SSH接続できない端末が出てきた。

ssh_dispatch_run_fatal DH GEX group out of range

原因

Diffie-Hellmanアルゴリズムで使用されるエフェメラルキーは、さまざまなサイズの係数(事前に生成された素数)に基づいています。OpenSSH 7.xの時点で、モジュラスの最小ビットサイズは2048に増加しています。古いSSH実装は、これほど大きなモジュラスをサポートしていない可能性があります。この場合、OpenSSH7.xはこれと同様のエラーを表示します。

IBM AIX:OpenSSH7.xにアップグレードした後のさまざまなsshの問題

解決方法

  1. AIXでOpenSSH 6.xを引き続き使用する
  2. 少なくとも2048ビットのモジュラスをサポートするバージョンに反対側のソフトウェアをアップグレードします。

この2つしか選択肢はない。

最小および最大のモジュラスサイズはOpenSSH7.xにハードコーディングされており、構成オプションを使用して変更することができないそうで、ああ、これはクライアントのSSHバージョンをあげなければ解決できないのか、、と。

参照

IBM AIX:OpenSSH7.xにアップグレードした後のさまざまなsshの問題

OpenSSHまたはAIXのアップグレード後、SSH接続が失敗する場合の対応方法

SSHポートフォワーディングサーバの刷新 サーバ入れ替え案件 覚書

古くなったサーバを入れ替えます。

Debian11 bullseye

設定した事

  • sshサーバ設定
  • パスワードの移行
  • Packetixサーバ設定
  • ntpクライアント設定

sshサーバ

# egrep -v '^\s*#' /etc/ssh/sshd_config |egrep -v '^\s*$'
Include /etc/ssh/sshd_config.d/*.conf
Port 4326
PermitRootLogin yes
ChallengeResponseAuthentication no
UsePAM yes
X11Forwarding yes
PrintMotd no
PermitUserEnvironment yes
AcceptEnv LANG LC_*
Subsystem       sftp    /usr/lib/openssh/sftp-server

sshで設定しやすいようにPATH通すため、PermitUserEnvironment yes にし、.bashrcにパスを追記した。

パスワードの移行

以下、2つのファイルにある移動しなければならないユーザ行をそれぞれ新サーバにコピーした。

/etc/passwd

/etc/shadow

Packetixサーバの設定

コンフィグファイルは、旧サーバでエクスポート、新サーバでインポートすると、ユーザを含めて設定は全て移行される。この点、Packetixは優れてるなといつも思う。

NTPクライアントの設定

入れ替え当日のテスト手順

  • 旧サーバを停止
  • LANケーブルの差し替え(DMZに新サーバを入れる)
  • ping疎通確認(LAN内から)
  • ssh接続確認(LAN内から)
  • ssh接続確認(インターネットから)
  • ポートフォワーディングおよびDMZ内の該当サーバにアクセスできるか
  • ポートフォワーディングアプリを利用して接続できるか
  • PacketixVPN接続(インターネットから)
  • iPhoneにてPacketixVPNへ接続でき、該当のホームページを表示できるか

Debian11 bullseye SSH接続で実行できないコマンドがある

update-rc.dが実行できない

Debian11 にて、SSH接続しながらターミナル上で設定をしていました。

いつも利用しているコマンドが実行できない事に気づき、bullseyeでは、このコマンドサポートされなくなったのかな?と、おもったら、shutdownも、rebootもできない事に気づき、インストールした本体に直接ディスプレイつけて操作したら、普通にshutdownできる事も。

PATHが通っていない

コマンドは、binフォルダや、sbinフォルダにあるのですが、そこにPATHが通っていない。これが原因でした。

@debian:~$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

sshd_configの設定

そこで、sshd_config にPATHの設定を書きました

#PermitUserEnvironment no

となっているので、

PermitUserEnvironment yes

このように書き換えました。.bashrcが読み込まれるようにしました。

# /etc/init.d/ssh reload
Reloading ssh configuration (via systemctl): ssh.service.

SSHサービスをリロードします。

.bashrcの最終行に追記

export PATH="$PATH:/usr/local/sbin:/usr/sbin:/sbin"

設定を反映させます

source ~/.bashrc

すると、ssh接続してもPATHが通るように

root@debian:~# printenv PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/usr/local/sbin:/usr/sbin:/sbin

もちろん、SSHで接続しなおしてもちゃんとPATHが通るようになりました。

Windows2019ServerでLANカード2枚刺しルーティングできるようにする

Windowsサーバでは単純にLANカードを2枚刺してもルータにはなりません。Windowsにて、LANカード同士、違うサブネットに対してIPパケットを回すルーティングを許可する必要があります。

許可する際に、GUIを用いて許可する事が可能で、その手順を示します。

サーバマネージャ起動

役割と機能の追加

役割ベースまたは機能ベースのインストール

リモートアクセスをインストール

ルーティングにチェック

Webサーバはデフォルトのまま

最終確認をしてインストール

リモートアクセスの構成

VPNのみを展開します

ルーティングとリモートアクセスの有効化

カスタム構成

LANルーティング

最終確認

Amazon EC2 自分の好きなプライベートアドレスサブネットに作成

この設定でできる事

Amazon EC2内にインスタンスを稼働させ、そのプライベートアドレスを、こちらで指定したサブネット、IPアドレスを利用させることができます。

現在、オンプレ環境で利用しているサーバ類をそのまま、クラウドにあげ、そのネットワーク構造体のままクライアントにアクセスさせたい時に利用します。

  • DMZで利用中のIPアドレス体系をそのままサブネットに反映
  • サーバも指定のIPアドレスを利用するように設定

VPC

Amazon Virtual Private Cloud (VPC) は、定義した論理的に分離された仮想ネットワークで AWS リソースを起動できるようにするサービスです。

ネットワークの塊というより、クラウドサーバ(ネットワークを含む)類の塊を作るイメージといったら伝わりますでしょうか?

VPCの作成

VPCを作成ボタンを押します。

VPCのみ作成する事や、VPCに合わせてサブネットも一緒に作成してくれる機能もあります。サブネットも一緒に作成すると、合わせてルートテーブルや、ゲートウェイもできるので、あまりネットワークの事を気にしなくても外部から接続できるVPCを作成する事ができます。

ここで、VPCのみを選択すると、サブネットなど自分で作成する自由度は上がりますが、AWSのネットワーク構成構築の基本的なところが分かってないと、EC2で作成した、インスタンスにもインターネットからアクセスできないなどになります。

サブネットの数も自動で2つずつできます。

DNSオプションもここで有効にできるので、一つ一つ入って設定するより楽に作成可能です。

配置図ができるので、ここを見ると何となくわかった気になります。

VPCの中に、サブネットがリージョンごとにパブリックと、プライベートに作成されます。ルート的にインターネット出口は同一セグメントに作成され、プライベートはそれぞれ別々に構成されます。パブリック側は、インターネットゲートウェイから外部にアクセスできるようになります。

ここでは、VPCのみ作成してみます。

ルートテーブルに違いが出る

サブネットまで一緒に作成した場合と、VPCのみ作成したときの違いはルートに出てきます。この辺が理解できていないと、インスタンスができてもインターネットからのアクセス不可で何も操作できない感じになります。

作成したメインルートテーブルをクリック

サブネットまで作成した場合、送信先は0.0.0.0/0どこへでもOKという形でインターネットゲートウェイが作成されます。

VPCのみ作成した場合は、ゲートウェイは作成されていません。

ゲートウェイを作成

インターネットゲートウェイを作成し、

指定したVPCにアタッチしておきます

設定したいVPCにアタッチ

自分が作成したサブネットに所属させると、インターネットゲートウエイが作成されずグローバルIPアドレスを取得していても、インターネットに出る事ができません。

VPC → ルートテーブル → [ルートを指定して] → ルートを編集

にて、ターゲット:インターネットゲートウェイを選択すると、先ほど作成したインターネットゲートウェイが出てきます。

これをやっておかないと、VPCにゲートウエイがない状態です。

インスタンスのパブリックIPv4アドレスが割り当てられているのに、いざ接続しようとしても、接続できない状態になります。上記のゲートウェイを追加したら接続できるようになりました。

サブネットの作成

VPCの中で、横のメニュー→サブネットをクリックし「サブネットを作成」ボタンをクリックします。

作成したVPCに紐づけます

IPv4 CIDR ブロック 192.168.1.0/24を作成します。

EC2でインスタンスを起動

インスタンスを起動というのが、インスタンスを作成するという意味になります。

EC2ダッシュボードから

無料利用枠で利用できるWindows Server 2019 Baseを稼働させます。

ここで作成するキーペアは重要で、後にリモートデスクトップ接続する時のパスワードを取得するために利用します。

ネットワーク設定で、作成したVPCを指定します。

セキュリティグループはファイヤーウォールの設定みたいなもんです。どこから接続ができ、どこへ接続ができるかを設定できます。

3389ポートに対して、インターネットのどこからでもアクセス可能というセキュリティグループを作成します。

高度なネットワーク設定を開くと、ネットワークインターフェース作成画面にてIPアドレスを指定する事が可能です。

インスタンスを起動すると、正常に起動しました。

WindowsServerにRDP接続します

インスタンスに接続します。

この時に、作成したキーペアを利用し、パスワードを取得します。

ローカルIPアドレス

192.168.1.50

をもったサーバが構築できました。

パブリックIPv4DNSを有効にしたい

上記の方法でサーバを構築すると、パブリックIPv4 DNSは有効になっておりません。これを有効にするためには、

VPCの設定を変更する必要があります。

DNSホスト名を編集をクリックし、DNSホスト名を有効化します。

すると、パブリックIPアドレスを持つインスタンスと対応するパブリックDNSホスト名を取得できるようになります。

RDSには2つのAZが必要

ご指定になった DB インスタンス testdb01 の作成リクエストは実行されませんでした。

The DB subnet group doesn’t meet Availability Zone (AZ) coverage requirement. Current AZ coverage: us-west-1a. Add subnets to cover at least 2 AZs. (Service: AmazonRDS; Status Code: 400; Error Code: DBSubnetGroupDoesNotCoverEnoughAZs; Request ID: 664248d6-994b-4ac0-8636-00d81503ee47; Proxy: null)

azとは

アベイラビリティゾーン (AZ) とは、1 つの AWS リージョン内でそれぞれ切り離され、冗長的な電力源、ネットワーク、そして接続機能を備えている 1 つ以上のデータセンターのことです。

これが必要になるのは

Amazon RDS マルチ AZ 配置では、Amazon RDS はプライマリデータベース (DB) インスタンスを自動的に作成し、データを別の AZ のインスタンスに同期的にレプリケートします。障害を検出すると、Amazon RDS は手動の介入なしにスタンバイインスタンスに自動的にフェイルオーバーします。

Amazon RDS マルチ AZ

この機能があるためではないかと考えられます。

このため、少なくとも2つのAZがあるVPCでなければ、作成できないと言っているかと。

簡単AmazonAWSで立ち上げたPostgreSQLに、同じサブネット内に起動したEC2のWindowsSrvインスタンスから接続する

PostgreSQLサーバの稼働はこちらから

この作成に際し、VPCと、セキュリティグループが設定されているものとします。

EC2内からAmazon RDSで稼働させたPostgreSQLに接続

EC2内から、パブリック公開していないAmazon RDS内に構築したPostgreSQLに接続します。

今回成功したのは同じサブネット内に入れたEC2のWindows2019サーバです。

今回構築できたのは上記の図に近いかと。

若干、Security group の考え方とサブネットが違うので、上記の図のままではないですけど、パブリック公開していないPostgreSQLに、公開したWindowsを踏み台にしてアクセスする事ができました。

EC2でWindowsインスタンスを稼働させる

Amazon EC2 って?

Amazon Elastic Compute Cloud (Amazon EC2)

インスタンスと呼ばれる仮想コンピューティング環境を構築する事ができます。

インスタンスを起動をクリック

無料利用枠のWindows Server 2019 を稼働させます。

無料利用可能なのは

1vCPU 1GiBメモリ

キーペアを作成し、ダウンロードしておきます。後で、リモートデスクトップするために、このキーを元にパスワードを取得します。

ネットワーク設定が重要

稼働させたPostgreSQLサーバが、どのサブネットにいるのか確認します。

私の環境では、PostgreSQLのIPアドレスが、172.30.1.0/24 にいたので、そこからサブネットIDはどれかというのが分かりました。このサブネットIDを控えておきます。

VPCももちろん、PostgreSQLと同じものを選択、さらにサブネットも、上記で調べたサブネットIDとおなじものにします。私が作成する時には、同じサブネットIDは出てこなかったので、コピペしたら、出てきました。

※サブネットを合わせるのが重要

パブリックIPも自動割り当てを行いました。

また、セキュリティグループも、PostgreSQLと同じセキュリティグループに入れてやります。ただし、ここは、同じじゃなくてもいいかも。

このセキュリティグループはファイヤーウォールとして動作します。宛先ポートや、ソースIPを指定する事でアクセスを拒否する事が可能です。

PostgreSQLへのアクセスポート5432と、リモートデスクトップ接続のための3389ポートを許可してあります。

この状態で、インスタンスを起動します。

インスタンスが利用できるまで少し時間がかかります。

リモートデスクトップ接続

インスタンスが実行中になったのを確認したら、リモートデスクトップ接続します。

アクションの中から接続をクリック

RDPクライアントをクリックし、リモートデスクトップファイルをダウンロードします。

パスワードを取得を押すと、インスタンス作成時にダウンロードしたキーペアからAdministratorのパスワードを取得する事ができます。

パスワードを復号化すると、パスワードが表示されます。これをコピーしておきます。

ダウンロードしたリモートデスクトップファイルを実行すると、リモートデスクトップへの接続が始まります。

取得したパスワードをコピペします。

Windowsへログインできます。

インターネットエクスプローラを立ち上げ、PgAdminをダウンロードします。

インターネットエクスプローラは、セキュリティが高くかかっていてちょっと面倒ですけど、頑張ってURLを追加していきながらお目当ての実行ファイルをダウンロードします。

ダウンロードできたら早速インストール

RDS → データベース → PostgreSQLで作成したデータベースの画面から、エンドポイントを調べておきます。

PgAdminでサーバを追加し、エンドポイントなどを貼り付けて設定します。PostgreSQLのパスワードは、インスタンス作成時に決めたパスワードを入れます。

すると、接続できました。

簡単AmazonAWS でPostgreSQLを立ち上げインターネットからアクセスさせる

無料枠で登録

クレジットカード情報などを登録し、始めてユーザ登録を行うと12か月間無料でAWSサービスを利用できます。

構築イメージ

ネットワークの事を考えておかないと、接続できないんです。PostgreSQLだけ簡単に立ち上げる事も出来るのですが、事前にVPCを構築しておくと、インターネット側からのアクセスも簡単にできます。

イメージ的にはこんな感じです。

ここでネットワーク作成手順が入ります

  • セキュリティグループ(外部からのアクセスを許可する)
  • サブネットの作成
  • VPCの作成

ネットワーク的にはこの3つを作成する必要があります。

VPCを作成

Virtual Private Cloud の略がVPCで、自前のクラウド空間を持つイメージで作成していきます。

VPCをクリック

右上のVPCを作成ボタンをクリックします。

視覚的にこのようなVPCができるよというのを表してくれるので少し分かった気になります。

オプション的にはこのように設定しました

セキュリティグループの作成

メニューからVPCにアクセスします。

セキュリティグループを作成します

右上のセキュリティグループを作成をクリック

セキュリティグループ名などを決めていきます。このセキュリティグループをどのVPCに反映させるかも、ここで決定します。

インバウンドルールに、どこのクライアント(インターネットのどこからでも)アクセスできるようにルールを書きます。

PostgreSQLのポートは5432です。

0.0.0.0/0 はアクセス制限しないという意味、どこからでもという意味になります。

アウトバウンドルールは特に変更する必要はありません。

PostgreSQLを立ち上げる

RDS → データベースの作成

PostgreSQLを選びます。

無料枠を使って

PostgreSQLのパスワードを決めます

課金されるといやだから、自動スケーリングはやめといてもいいかも

VPCに、上記で作成したVPCを選択します。セキュリティグループも同様です。

パブリックからアクセスOKにするため、パブリックアクセスはありにします。

とりあえずパスワード認証でアクセスできるようにします。

Postgres無料枠の条件

  • Amazon RDS 無料利用枠は、12 か月間利用できます。
  • シングル AZ の db.t2.micro、db.t3.micro、または db.t4g.micro インスタンスでの 750 時間分の Amazon RDS。
  • 20 GB の汎用ストレージ (SSD)。
  • 自動化されたバックアップ用の 20 GB のストレージ、およびユーザー起動による任意の DB スナップショット。

ネットワーク情報・接続方法

一連の流れの中でVPC上に、パブリックIPを持ち、インターネットのどこからでもアクセスできるPostgreSQLサーバが起動しました。

DB識別子に、作成したデータベースが現れるのでこれをクリック

接続とセキュリティ

エンドポイントとポートに接続に必要な情報が記載されています。

これを、PgAdmin に設定します。

パスワードは、PostgreSQL作成時に決めたパスワードを設定します。

すると接続できました。