Mac上でFirebaseを初期設定を行う

既にHomebrewが入っていて、
Firebase用のGoogleアカウントを既に所持していることが前提。

後述するFirebase CLIのセットアップでは
・Database
・Firestore
・Functions
・Hosting
・Storage
が選択できるが、
自分の場合は、FirestoreとHostingを選択する。
※用途によって選択する。

[参考]
Firebaseの各機能を3行で説明する - Qiita

インストール

nodebrew

Node.jsをバージョン管理できるnodebrewを先にインストールする。

$ brew install nodebrew

以下のコマンドをうち、表示されたパスを~/.bash_profileにExportする。

$ nodebrew setup

========================================
Export a path to nodebrew:

export PATH=$HOME/.nodebrew/current/bin:$PATH
========================================

$ echo 'export PATH=$HOME/.nodebrew/current/bin:$PATH' >> ~/.bash_profile
$ source ~/.bash_profile

node.jsをインストール（[stable:安定版]をインストール）

$ nodebrew install-binary stable

確認

$ nodebrew list
v10.14.2

current: none

安定版を使用する設定

$ nodebrew use stable
$ node -v
v10.14.2

npmの更新

$ npm update -g npm

firebase

インストール

$ npm install -g firebase-tools

ログイン

https://firebase.google.comを開き、コンソールにアクセスする。
コンソールにて、任意のプロジェクトを作成する。

その後、以下のコマンドでログインを行う。

$ firebase login

すると以下のような「匿名の使用情報やエラーレポート情報を収集しても良いか？」と聞かれるので
Y/nで回答する。

"? Allow Firebase to collect anonymous CLI usage and error reporting information? (Y/n)"

するとブラウザで開くので、対象のGoogleアカウントを選択肢、Firebase CLIに権限許可を与えると、ログインに成功する。

サンプルアプリは次の記事で紹介する。

[参考]
【2018年版】macのhomebrewでnodebrew入れてからnode.jsを入れるまで - Qiita

Mac上でFirebaseを初期設定を行う

既にHomebrewが入っていて、
Firebase用のGoogleアカウントを既に所持していることが前提

インストール

nodebrew

Node.jsをバージョン管理できるnodebrewを先にインストールする。

$ brew install nodebrew

以下のコマンドをうち、表示されたパスを~/.bash_profileにExportする。

$ nodebrew setup

========================================
Export a path to nodebrew:

export PATH=$HOME/.nodebrew/current/bin:$PATH
========================================

$ echo 'export PATH=$HOME/.nodebrew/current/bin:$PATH' >> ~/.bash_profile
$ source ~/.bash_profile

node.jsをインストール（[stable:安定版]をインストール）

$ nodebrew install-binary stable

確認

$ nodebrew list
v10.14.2

current: none

安定版を使用する設定

$ nodebrew use stable
$ node -v
v10.14.2

npmの更新

$ npm update -g npm

firebase

インストール

$ npm install -g firebase-tools

ログイン

https://firebase.google.comを開き、コンソールにアクセスする。
コンソールにて、任意のプロジェクトを作成する。

その後、以下のコマンドでログインを行う。

$ firebase login

すると以下のような「匿名の使用情報やエラーレポート情報を収集しても良いか？」と聞かれるので
Y/nで回答する。

"? Allow Firebase to collect anonymous CLI usage and error reporting information? (Y/n)"

するとブラウザで開くので、対象のGoogleアカウントを選択肢、Firebase CLIに権限許可を与えると、ログインに成功する。

サンプルアプリは次の記事で紹介する。

[参考]
【2018年版】macのhomebrewでnodebrew入れてからnode.jsを入れるまで - Qiita

【Mac】HomebrewでMySQLをインストールする

自分用メモ

※homebrewが既に入っている前提
※またSequel Proを使用するためには現時点では、デフォルトのMySQL8.0はサポートされていないので
追記の5.7をインストールする必要がある。

インストール

$ brew install mysql

2018/11/30時点だと、MySQL8.0がインストールされる。
この時点だとでログインしようとすると・・・

$ mysql -uroot
ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO)

とエラーが出る。

対応策は以下のサイトさんのやり方を踏襲
blog.kuromusubi.com
※同じやり方をしても何故かコマンドが通らない場合は、「flush privileges;」を叩いてみる。

自動起動有効化

brew servicesというコマンドで自動有効化できるっぽい。
qiita.com

$ brew services start mysql

これで、LaunchAgentsにシンボリックリンクを置かなくていいっぽい。

追記

Sequel Proが現時点では、8.0に対応していないので
5.7をインストールすることにした。

インストール

8.0を先にインストールしている場合は

$ brew uninstall mysql

$ rm -rf /usr/local/var/mysql

5.7をインストール

$ brew install mysql@5.7

mysql@5.7 is keg-only, which means it was not symlinked into /usr/local,
because this is an alternate version of another formula.

If you need to have mysql@5.7 first in your PATH run:
echo 'export PATH="/usr/local/opt/mysql@5.7/bin:$PATH"' >> ~/.bash_profile

デフォルトだとパスが通ってないのでパスを通す。

$ echo 'export PATH="/usr/local/opt/mysql@5.7/bin:$PATH"' >> ~/.bash_profile

$ soruce ~/.bash_profile

確認

$ mysql -v

rootにパスワードの設定

$ mysqladmin -u root password 'yourpassword'

最後に自動起動設定

$ brew services start mysql@5.7

my.cnfの場所

$ mysql --help | grep my.cnf
                      order of preference, my.cnf, $MYSQL_TCP_PORT,
/etc/my.cnf /etc/mysql/my.cnf /usr/local/etc/my.cnf ~/.my.cnf

上記の順番で読み込まれる。

あまり環境を汚したくないので、以下の場所でmy.cnfを設定

$ vim /usr/local/etc/my.cnf

[参考]
Install MySQL 5.7 on macOS using Homebrew · GitHub
MySQL5.7をHomebrewでmacOSにインストールする手順 | WEB ARCH LABO

【WordPress】Wordmoveを使用して、本番環境と開発環境を同期させてみる

Wordmoveについての詳細は省くが、簡単に説明すると
Wordmoveとは、WordPressの環境を簡単に、移行させることができるRuby製のツール。

github.com

使用例としては、以下のような用途で使用できる。
・記事やプラグインの設定などを一度ローカルで行って問題がない場合、本番環境へ更新を行いたい。
・本番環境と同じデータやプラグインを使用し、ローカルでテストを行いたい。

インストール

※rubyがインストールされていることが前提

$ gem install wordmove

確認

$ wordmove -v

設定ファイル作成

以下のコマンドを使用することで、「Movefile」というファイルが作成される

$ wordmove init

Movefileの設定

global:
  sql_adapter: default  # wpcliがローカルにあるなら、wpcliを設定。

local:
  vhost: "ローカルURL"
  wordpress_path: "/var/www/html/" # use an absolute path here

  database:
    name: "DB名"
    user: "ユーザ"
    password: "パスワード"
    host: "ホスト"

production:
  vhost: "サイトURL"
  wordpress_path: "WPの絶対パス" # use an absolute path here

  database:
    name: "DB名"
    user: "ユーザ"
    password: "パスワード"
    host: "ホスト"

  exclude:
    - ".git/"
    - ".gitignore"
    - ".sass-cache/"
    - "node_modules/"
    - "bin/"
    - "tmp/*"
    - "Gemfile*"
    - "Movefile"
    - "wp-config.php"
    - "wp-content/*.sql"

  ssh:
    host: "リモートホスト"
    user: "ユーザ"
    port: 22
    rsync_options: "--verbose"

  forbid:
    push:
      db: true
      plugins: true
      themes: true
      languages: true
      uploads: true
      mu-plugins: true
    pull:
      db: false
      plugins: false
      themes: false
      languages: false
      uploads: false
      mu-plugins: false

globalセクションの「sql_adapter」では「default」か「wpcli」を選択できる。
sql_adapterの中身は、ローカルと本番でURLの変換するだけの機能。
defaultだと、dump.sqlテキスト内を走査して、文字列変換をしている。
wpcliではwp-cliのコマンドを使って、文字列変換をしている。

また他のサイトでは、あまり紹介していないが
間違って本番にpushしてしまわないようにforbidセクションを使用すれば、細かくpush可否の制限ができる。

Dockerイメージも公開されており、Dockerで開発環境を作る際は、すごい便利。
https://hub.docker.com/r/welaika/wordmove/

[リモートからローカルへ]
例１）DBのみをプルする例

$ wordmove pull -e production -d

例２）すべてをプル

$ wordmove pull -e production -all

例３）検証モードでプル（実際にはプルしない）

$ wordmove pull -e production -all -s

[ローカルからリモートへ]
例）DBのみをプッシュする例

$ wordmove push -e production -d

[オプション一覧]
--all # ファイル全部
-w # `/wp-content/`ディレクトリ（除外したファイル以外）のみ
-u # `/wp-content/upload/`ディレクトリのみ
-t # `/wp-content/theme/`のみ
-p # `/wp-content/plugins/`のみ
-l # `/wp-content/language/`のみ
-d # データベースファイルのみ
-v # [TBD] verbose
-s # dry runモードで実行、実際にはファイル転送されない
-e # 環境（push先・pull元）を指定
-c # `wp-config.php`のみ
-h # wordmoveの使い方

[参考]
Wordmoveの基本操作 - Qiita

【fail2ban】再起動すると今までBanしたIPを再度ScanしBanするため、同じメールが大量に届く問題

自分用メモ。また実際に検証したわけではないのあしからず。

調査したところ、同じようなことを思っていた人がいた。
github.com
github.com

received duplicates of all ban report emails.

Also this is "reimplemented" in newer version (>= 0.10) - since parameter norestored introduced (and all mail-actions got norestored = 1), see RFE #1852.

Back to 0.9 - the active bans are known (tickets saved in the database), so it will be restored after restart - and all actions (mail-actions inclusive) will be repeated after restart.

So only one option currently - update to newer version.

by Jail reload without log rescan · Issue #2091 · fail2ban/fail2ban · GitHub

上記のリンクを見ると、どうやら「fail2ban 0.10」から「norestored = 1」というパラメータが全てのmailアクション系追加されたため、このパラメータが１の場合、再スキャンやメールを再度送信するといった動作はしなくなるっぽい。
そして0.9だとどうしようもなく、現在有効な手段としては、0.10以上にするしかないとのこと。

ただ現在、自分は0.9.3を使用しており、apt-getからでは0.10はインストール出来ない。

ansibleのroleを使ってる人がすでにいたので、導入するときは以下のやり方をもとに導入する。
gitlab.lakedrops.com

【fail2ban】BanしたIPアドレス一覧と、間違えてBanされてしまった場合の対象方法

fail2banで「sshd」のjail設定されているものとした場合、

$ sudo fail2ban-client status sshd

と打てば、sshdのjailでBanされたIPアドレス一覧が表示される。

また誤ってBanされている場合のIPを戻す方法は

$ sudo fail2ban-client set sshd unbanip {BANしたIPアドレス}

と打てば良い。

[参考]
Linux：fail2banで防ぐ「DoS/DDoS攻撃」対策 - よしまさのブログ

【Rootkit Hunter】「Warning: The file properties have changed:」という警告が出た時の対応方法

自分の場合、Slackで通知が来る設定にしているのだが
「Warning: The file properties have changed:○○○○○○○○...」
というようなエラーが届くようになった。

調べてみたら、システムやパッケージをアップデートしたら、
以下のコマンドで、rkhunterのプロパティデータベースを"手動"で更新する必要があるみたい。

$rkhunter --propupd

Means update your system file properties. This is a necessary step to establish a foundation database file to compare scans. There is another command called --update which is not the same. On a clean install, the first run of propupd, creates a new database file. On later scans, running the propupd command, updates the database file. So, to update the database file, you are satisfied you have only trusted source system file changes. RKH offers choices, in the CONF, in how you verify system file changes. You can use your package manager and other resources to verify changes reported in the log file.

Note the RKH team do not maintain an independent properties database for each distro and their various releases. The properties database file is always maintained locally by you.

By Rootkit Hunter / Wiki / propupd

要は、rkhunterスキャン時に、このプロパティデータベースのデータと比較して、
コマンドなどが意図されていない変更がされていないかチェックしているっぽい。

rkhunter --propupdを叩くことで、現在のシステム、パッケージにあったプロパティ情報を更新しているということか。

なので

１）rkhunter- propupdを実行
２）再度スキャン

をしたら、警告はでなくなった。

以上