zuntan02のはてなブログ

備忘録的なものです。時々職場の技術者ブログにも転記してますが、メインはこちらで。

【Mattermost】Slack用のGAS秘書botをMattermostに向けたメモ

【前提】

既に
qiita.com
を参考に、GASからSlack向けにメッセージを投げるbotがあったので、それをMattermostに向けたときのメモです。


【サマリ】

01.[システムコンソール]で[カスタム統合機能]を諸々有効にする
02.アカウントの[統合機能]で[内向きのウェブフック]を作成
03.botのPOST処理を修正

【作業メモ】

01.[システムコンソール]で[カスタム統合機能]を諸々有効にする

f:id:zuntan02:20170425185654p:plain

内向きのウェブフックを有効にする: 有効
外向きのウェブフックを有効にする: 有効
カスタムスラッシュコマンドを有効にする: 有効
OAuth 2.0サービスプロバイダーを有効にする: 無効
統合機能の管理を管理者のみに制限する:無効
★今回は利用者に自由に使ってもらう意図で無効化していますが、運用方針に合わせてください。
統合機能によるユーザー名の上書きを許可する:有効
統合機能によるプロフィール画像アイコンの上書きを許可する:有効
★[ユーザー名の上書き]と[プロフィール画像アイコンの上書き]を両方有効にするとフィッシング攻撃を許してしまう可能性があります。今回は利用者が限られているため有効としていますが、運用方針に合わせてください

02.アカウントの[統合機能]で[内向きのウェブフック]を作成

  • アカウントメニューから[統合機能]

f:id:zuntan02:20170425185716p:plain

  • [内向きのウェブフック]を作成

f:id:zuntan02:20170425185724p:plain

  • タイトルと出力先のチャンネルを指定

f:id:zuntan02:20170425185731p:plain
→ウェブフック用のURLが払い出されます。

03.botのPOST処理を修正

payloadに乗せるアイテムが一部異なる

[メモ] SlackとMattermostそれぞれのincomingWebhookへのポスト方法の違い – Nobwak's Lair


例)
"icon_emoji" : ":information_desk_person:"

"icon_url":"画像のURL"

とか


上記を変えてもPOSTでエラー。
<ウェブフックURL>のリクエストに失敗しました(エラー: 400)。サーバー応答の一部: {"id":"web.incoming_webhook.parse.app_error","message":"外部からのデータを解析できません","detailed_error":"","request_id":(中略)(応答の全文を見るには muteHttpExceptions オプションを使用してください)

などとなった。postにcontentTypeが必要だった。

   'contentType': 'application/json',

参考:
Class UrlFetchApp  |  Apps Script  |  Google Developers
のMake a POST request with a JSON payload.のところ。

というわけで(この秘書botに関しては)POST周りは以下のようにしたら動いたよというメモでした

//slackへポスト
function postSlack(payload)
{
  // POSTオプション
  var options = {
    "method" : "POST",
    "payload" : JSON.stringify(payload)
  }

  // アクセス先
  var url = "https://hooks.slack.com/services/XXXXXX/XXXXXX/XXXXXXXXXXXXXXX";
  // POSTリクエスト
  var response = UrlFetchApp.fetch(url, options);
  // HTML結果を取得(引数のcharsetは設定したほうが良い)
  var content = response.getContentText("UTF-8");
}

//mmostへポスト
function postMmost(payload)
{
  // POSTオプション
  var options = {
    "method" : "POST",
    "contentType": "application/json",
    "payload" : JSON.stringify(payload)
  }

  // アクセス先
  var url = "https://hogehoge/hooks/XXXXXXXXXXXXXXXXXXXXXXXXXXX";
  // POSTリクエスト
  var response = UrlFetchApp.fetch(url, options);
  // HTML結果を取得(引数のcharsetは設定したほうが良い)
  var content = response.getContentText("UTF-8");
}

以上、何か参考になれば。

【Linux】find | xargs cpでヒットするファイルを階層・タイムスタンプを保ったままコピー

■コマンド
ここ3日分のファイルを対象に、階層を保ったままコピー

find . -mtime -3 -type f -print0 | xargs -0 cp --parents -p -t 宛先ディレクトリ


■オプションメモ

find -print0:-print0オプションを有効にすると区切り文字がスペースから \0 に変更されます
xargs -0:-0オプションを指定されると \0 を区切り文字として扱います

cp --parents  use full source file name under DIRECTORY
cp -p = --preserve=mode,ownership,timestamps
cp -t --target-directory=DIRECTORY

【AWS】RDS(MySQL)のUpgradeについて、リードレプリカと本体とどちらを先にUpgradeするか問題

■結論

リードレプリカを先にUpgradeする必要がある。

■検証

→DBインスタンスの変更でマスタ側のみUpgradeしようとすると以下のメッセージ

この DB インスタンスには 1 つまたは複数のリードレプリカがあります。すべての対応するリードレプリカのストレージが DB インスタンスのものと同じ(またはそれ以上)であることを確認してください。また、すべての対応するリードレプリカのエンジンのバージョンが DB インスタンスのものと同じであることも確認してください。<リードレプリカ名>

→そのままDBインスタンスの変更を実施

One or more of the DB Instance's read replicas need to be upgraded: <リードレプリカ名>(Service: AmazonRDS; Status Code: 400; Error Code: DBUpgradeDependencyFailure; Request ID: hogehoge)

リードレプリカを先にUpgradeする必要があることが分かる。

【NewRelic】WindowsServerへのNewRelic監視エージェント インストール

【参考】
docs.newrelic.com

【作業】
■NewRelic Servers for Windows

1)NewRelic-[Servers]-[Add more]-[Choose a platform]でWindowsを選択
 →下にmsiとかのDLリンクが出てくるので必要なものをDL。ここでは
 [NewRelicServerMonitor_x64.msi]をDL

2)上記をWindowsServerでインストール
 インストーラの途中でライセンスキーを聞かれるので用意しておくこと


以上

【AmazonLinux】gitlabのバージョンアップ(8.10.0→9.0.2)メモ

zuntan02.hateblo.jp
この環境がふるくなってきたので最新化したら例によって苦しめられたのでメモ。

# Update前の状態を確認
gitlabのrootログインにて
[管理エリア]-[概要]-[Components]でバージョンを確認

GitLab 8.10.0
GitLab Shell 3.2.0
GitLab API v3
Git 2.7.4
Ruby 2.1.8p440
Rails 4.2.7
PostgreSQL 9.2.17

■Node.jsが入っていない環境だったのでインストール(ないと日本語化パッチ適用中にエラーになった)
# Node.jsのインストール
# 先にnvm(Node Version Manager)をインストールする
su -
cd ~
git clone https://github.com/creationix/nvm.git ~/.nvm && cd ~/.nvm && git checkout `git describe --abbrev=0 --tags`

# パスを通す
. ~/.nvm/nvm.sh
nvm --version
# 0.33.1

# 以下を、~/.bashrc 等に追記して、起動時に読み込むようにしておく
続きを読む

【Mattermost】3.6.1→3.7.3にUpdateしたメモ

前に
zuntan02.hateblo.jp

これで構築した環境のバージョンアップ作業メモ。

■事前作業

# Upgradeガイド確認
https://docs.mattermost.com/administration/upgrade.html

バックアップ

AWS EC2だったのでのスナップショット取得で。
MySQL dumpとかしたほうがいいかもしれないけども面倒なので)

パッケージを取得・展開
cd /usr/local/src/
wget https://releases.mattermost.com/3.7.3/mattermost-3.7.3-linux-amd64.tar.gz
tar xvzf mattermost-3.7.3-linux-amd64.tar.gz
サービスの停止~設定ファイル・データのコピー~サービス再開
/etc/init.d/mattermost stop
/etc/init.d/mattermost status

# 設定ファイル(config.json)の差し替え
cd /usr/local/src/mattermost/config
mv config.json config.json_org
cp -p /home/tcmobile/config.json ./

# ローカルストレージ(./data)のコピー
cp -rp /opt/mattermost/bin/data /usr/local/src/mattermost/bin/

# 所有者変更
chown -R mattermost:mattermost /usr/local/src/mattermost/

# アプリケーションディレクトリの新旧差し替え
mv /opt/mattermost /opt/mattermost_old
mv /usr/local/src/mattermost /opt/

# 再開
/etc/init.d/mattermost start
/etc/init.d/mattermost status
システムコンソール_サーバーログでログ確認

OK

【さくらのレンタルサーバ+WordPress】異なるバージョンのPHPを利用している時の注意点

【メモ】

qiita.com

上記設定の際、.htaccessによりphp.cgi が読み込まれるようになるので、Wordpressを丸ごとバックアップ(BackWPupなど)してから戻したときはUpLoad後にphp.cgiの権限に実行権をつけること。

【ハマり状況1】WordpressサイトがInternal Server Error

BackWPupで取得したWordpressの環境を別ディレクトリに戻してみたらInternalServerError!
php.cgiの権限に実行権を付ける
→既存のものに合わせて、0715としたら動いた。

【ハマり状況2】BacWPupがToo Many Redirects

上記Wordpressは動いたものの、BackWPupが動かなくなった

  • SNI SSL化している
  • http→httpsへの301リダイレクト処理では「wp-cron.php」をredirectの対象外としている(つもり)

→情報を見るとToo Many Redirectsとなっており、「ジョブが開始されましたが、10秒間応答しません。」となる

【解決】
.htaccessのRewriteCondの条件を以下のようにする

# for BackWPup
RewriteCond %{REQUEST_URI} !.*wp-cron.php$

※ !^/wp-cron.php$だと変更後のPHP(/php.cgi)の処理が挟まるときにマッチしない模様

全体としてはこんな感じ

Action myphp-script /php.cgi
AddHandler myphp-script .php .html

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /

# for BackWPup
RewriteCond %{REQUEST_URI} !.*wp-cron.php$

# http to https
RewriteCond %{ENV:HTTPS} !^on$
RewriteCond %{HTTP:X-Sakura-Forwarded-For} ^$
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress
</IfModule>

以上、何かの参考になれば。