zuntan02のはてなブログ

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

G-RAID (Removable)が初期状態ではRAID0だったのでRAID1(ミラーリング)にしたメモ

【本作業の該当商品】

G-Technology (HGST) G-RAID Removable 8TB USB3.0&FireWire 800 対応 外付けハードディスク

【G-RAID Removable UtilityでRAID1に変更】

公式ウェブサイト
support.g-technology.com

ダウンロードタブから、「G-RAID Removable Utility」をDLしてinstall
ソフトウェアおよびファームウェアのダウンロード | G-Technology
f:id:zuntan02:20170522121708p:plain

解凍して実行
f:id:zuntan02:20170522121735p:plain
f:id:zuntan02:20170522121743p:plain

RAID1に変更
f:id:zuntan02:20170522121749p:plain

警告に[はい(Y)]
f:id:zuntan02:20170522121816p:plain

完了。
f:id:zuntan02:20170522121809p:plain

以上でRAID1化完了です。

あとは、WindowsPCなら[管理ツール]-[コンピュータの管理]-[ディスクの管理]で割り当てて利用可能。

【その他マニュアルなど】
support.g-technology.com

以上

ラズパイ2(RaspberryPi2)にCentOS7を入れてみる

■作業概要

1)(WindowsPCで)ラズパイ用CentOS7のイメージをDL、SDカードに書き込み
2)CentOS起動+ログイン
3)初期設定
4)ディスクスペースの拡張

1)(WindowsPCで)ラズパイ用CentOS7のイメージをDL、SDカードに書き込み

DD for windowsをインストー

WindowsPCで実施する場合、事前に以下のツールをインストールしておく

CentOSパッケージのダウンロード

https://buildlogs.centos.org/centos/7/isos/armhfp/
より、RaspberryPi2用パッケージ
CentOS-Userland-7-armv7hl-Minimal-1611-test-RaspberryPi2.img.xz
をDLし、解凍します。
CentOS-Userland-7-armv7hl-Minimal-1611-test-RaspberryPi2.img

DD for Windowsを起動してSDカードに書き込み

ディスク選択でusb(micro-SD)を選択
(SDカードが選択できないときはexeの互換モードを使って起動するとよい)

ファイル選択で先ほど解凍したcentosを選択
CentOS-Userland-7-armv7hl-Minimal-1611-test-RaspberryPi2.img

で[<<書込<<]
f:id:zuntan02:20170521114350p:plain

2)CentOS起動+ログイン

micro-SDをRaspberry Pi 2に差し込んで起動

初期ID/PWは
login : root
password: centos

3)初期設定

109キー日本語レイアウトのキーボードの設定をします。

■ラズパイのCentOS側で
localectl set-keymap jp106
localectl set-keymap jp-OADG109A

##System Localeを変更もしておきます
localectl set-locale LANG=ja_JP.utf8

##localectlで確認
localectl

#System Locale: LANG=ja_JP.utf8
#       VC Keymap: jp-OADG109A
#      X11 Layout: jp
#       X11 Model: jp106
#     X11 Options: terminate:ctrl_alt_bksp

4)ディスクスペースの拡張

ルート領域をSDカードいっぱいまで拡張したい

cat /root/README

== CentOS 7 userland ==

If you want to automatically resize your / partition, just type the following (as root user):
/usr/local/bin/rootfs-expand

→以前の.rootfs-repartitionとは変わっている模様。
/usr/local/bin/rootfs-expand
で拡張された。

df -h
ファイルシス   サイズ  使用  残り 使用% マウント位置
/dev/root         57G  907M   54G    2% /
devtmpfs         458M     0  458M    0% /dev
tmpfs            462M     0  462M    0% /dev/shm
tmpfs            462M   12M  450M    3% /run
tmpfs            462M     0  462M    0% /sys/fs/cgroup
/dev/mmcblk0p1   500M   49M  452M   10% /boot
tmpfs             93M     0   93M    0% /run/user/0

初期状態では外部からのSSH接続などは制限されていないため、DHCPで付与されたIPを使ってSSH接続ができる。


yum updateできない問題対策

yum update で以下のエラーメッセージが出た

http://mirror.centos.org/altarch/7/kernel/armhfp/kernel-rpi2/repodata/repomd.xml: [Errno 14] HTTP Error 404 - Not Found

【参照URL】
http://qiita.com/Leonardo-mbc/items/2fb67a6f860aa33fd9bd

cd /etc/yum.repos.d
続きを読む

【AWS】AWSからRDSサーバの再起動予告が来たけどリスケされたメモ

【流れ】

  • AWSから指定期間中、メンテナンスウィンドウでマシンの再起動があるよ(だけどMultiA-Zにしておけばフェイルオーバー時間の停止で済むよ)と予告があった。
  • SingleA-ZなRDSだったので、該当期間のメンテナンスウィンドウ前にRDSをMuitiA-Z化した(サービス停止なし)。
  • が、該当時間を過ぎても再起動されていない(failoverしてない、AZが変わっていない)
  • その週の終わりころに「再起動できなかったので翌週やります」という内容の連絡

 →SingleA-Zに戻した(サービス停止なし)。

  • 翌週のメンテナンスウィンドウ前に再度MultiA-Z化
  • 今度はメンテナンスウィンドウで再起動された。フェイルオーバー中20秒ほど重かった様だがエラーなし
  • RDSのフェイルオーバーおよび再起動が完了したのを確認してSingleA-Zに戻した
■最初の案内メール

One or more of your Amazon RDS DB Instances have been scheduled to receive system upgrades during the maintenance window you have chosen as per the schedule below.
(中略)
The maintenance activities are planned during 2017-5-5 21:00 UTC (Friday) to 2017-5-12 20:59 UTC (Friday).

Please note that while the system upgrades complete, your database will have an availability impact for a few minutes during your maintenance window. For Multi-AZ deployments, this impact is limited to the amount of time it takes for a failover to complete. Therefore, please cross check your maintenance window settings to ensure that they are set as per your needs using the schedule above.

Google翻訳
1つまたは複数のAmazon RDS DBインスタンスが、以下のスケジュールに従って選択したメンテナンス期間中にシステムアップグレードを受けるようスケジュールされています。
(中略)
メンテナンス活動は、2017-5-5 21:00 UTC(金曜日)〜2017-5-12 20:59 UTC(金曜日)に計画されています。

システムのアップグレードが完了している間は、メンテナンス期間中にデータベースの可用性が数分間影響を受けることに注意してください。マルチAZ配備の場合、この影響はフェイルオーバーが完了するまでに要する時間に制限されます。したがって、上記のスケジュールを使用して、必要に応じてメンテナンスウィンドウの設定を確認してください。

■再実行案内

Due to unexpected circumstances, we could not perform maintenance during this period. The upgrades for the resources listed below will now occur between 2017-5-12 21:00 UTC (Friday) and 2017-5-19 20:59 UTC (Friday).

(Google翻訳)
予期せぬ事態のために、この期間中はメンテナンスを行うことができませんでした。下記のリソースのアップグレードは、UTC(金曜日)21:00 UTC(金曜日)と2017-5-19 20:59 UTC(金曜日)の間に行われます。

対象の期間を過ぎても強制メンテナンスが実行されない場合はこんなパターンかもしれません。
メモまで。

【Wii修理】Wiiのピックアップレンズ交換したメモ201705

【まとめ】

長年使ってたWiiがディスクを読み込まなくなってきた。
モーターの高さ調整でピックアップの距離を変更
ピックアップレンズ横のネジ調整
では解決しなかったので、
ピックアップレンズの交換
を行ったところ、サクッと復活した。長期間使っててだんだんディスク読み込まなくなってきた、って人は、上記ネジによる調整は時間の無駄かも(自分はネジをいじりすぎて元の位置が分からなくなったりして、結局まる1日くらい捨ててしまった……)。ピックアップレンズ(1200円くらい)を買って交換するのが良さそうです。

分解手順は上記リンクからどうぞ(手抜)。

【購入品メモ】

Wii 修理用ピックアップレンズ Wii全型番対応 RAF-3350

「全型番対応」とあるけど、実際は

  • RAF-3350


  • RAF-3355

の2種類があるようなので、Wiiを分解した時点でレンズユニットのフィルムケーブルに貼ってあるQRコードで型番を確認してから購入しましょう。

交換用レンズユニットが届いたら
・フィルムケーブルの中央にある静電気防止のショート回路(半田の粒)をぺりっと剥がしてそこだけ断線させる。
 →半田ゴテでやると、余計な個所を焼いちゃうかもしれないので、爪でぺりっと剥がしたほうがいいような気がします。
・旧レンズの横についてる白い位置決めパーツを取り外して、新レンズに取り付ける

で、元通りに組み立てればOK。

久々にお値打ちな感じの修理で楽しかった。

【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する必要があることが分かる。