Rubyと筋肉とギターとわたし

筋トレが仕事です

【Linuxコマンド】特定の文字列を含むファイルを検索する

f:id:rdwbocungelt5:20180919135208j:plain

こんにちはもてぃです。

smot93516.hatenablog.jp

前のエントリも合わせて記事にします。

特定の文字列を検索して、文字列置換まで合わせてやりたいと思ったので備忘録として。。。

findを使う

$ find . -type f -print | xargs grep '検索したい文字列'

最初はこれをうまく使ってやろうと思いました。

が、これだと検索したファイル名のパス:検索した文字列の形で出てきます。

例えばこんな感じ。

$ cd html # => 配下にindex.html, mobile.htmlなどがあるとする

$ find . -type f -print | xargs grep 'head'
./html/index.html: <head>
./html/index.html: </head>
./html/mobile.html: <head>
./html/mobile.html: </head>

文字列置換と合わせてやりたい場合に後ろの検索した文字列は本当に邪魔。

どうにかして、ファイルパスのみ表示したかった。。。

ということでgrep再帰的に使う

grepのオプションを使えば解決出来ました。

-r : 再帰的にgrepコマンドを実行
-n : 行番号を表示する
-w : 文字列全体にマッチする場合
-l : ファイル名だけを出力

-l : ファイル名だけを出力

これらをうまく使います。

$ grep -rlw . -e 'head'
./html/index.html
./html/index.html
./html/mobile.html
./html/mobile.html

あとはxargssedを使って、文字列を置換してやればおkって感じです。

以下はSSL化の際のhttpをhttpsへ置換するコマンド。

# カレントディレクトリ配下全てのファイルのhttpをhttpsへ置換
$ grep -rlw . -e 'https' | grep html | xargs sed -i -e 's/http:/https:/g'

終わりに

以下の記事を参考に致しました。

ありがとうございます。

qiita.com

nginxのエラーログが出力されない時は。。。

nginx

参考にしたのは以下の本。

エラー画面が出ているのに全然エラーログが吐き出されなかったのですが、この本に助けられました。

nginx.conf

kusanagiコマンドでwordpress環境を構築しました。

以下がnginx.conf

rootは /etc/nginx/nginx.confで設定しています。

## default HTTP
server {
    listen       80;
    server_name  default_server;
    access_log  /home/kusanagi/wordpress/log/nginx/access.log main;
    error_log   /home/kusanagi/wordpress/log/nginx/error.log warn;
    index  index.php index.html index.htm;

    charset UTF-8;
    client_max_body_size 16M;

    location / {
    try_files $uri $uri/ /index.php?$args;
    }

    rewrite /wp-admin$ $scheme://$host$uri/ permanent;

    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   /usr/share/nginx/html;
    }

    location ~ /\.ht {
        deny  all;
    }

    location = /favicon.ico {
    log_not_found off;
    access_log off;
    }

    location ~* /\.well-known {
        allow all;
    }

    # 以下ネストが変になってます。
    location ~* /\. {
        deny all;
    }

    #include templates.d/multisite.conf;

    location ~* /(?:uploads|files)/.*\.php$ {
        deny all;
    }

    location ~* \.(jpg|jpeg|gif|png|css|js|swf|ico|pdf|svg|eot|ttf|woff)$ {
        expires 60d;
        access_log off;
    }

    location ~* /blog/wp-login\.php|/wp-admin/((?!(admin-ajax\.php|images/)).)*$ {

        satisfy any;
        allow 0.0.0.0/0;
        allow 127.0.0.1;
        deny all;
        auth_basic "basic authentication";
        auth_basic_user_file  "/home/kusanagi/.htpasswd";

        location ~ [^/]\.php(/|$) {

            fastcgi_split_path_info ^(.+?\.php)(/.*)$;
            if (!-f $document_root$fastcgi_script_name) {
                return 404;
            }
            #fastcgi_pass 127.0.0.1:9000;
            fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock;
            fastcgi_index index.php;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            include fastcgi_params;
            fastcgi_buffers 256 128k;
            fastcgi_buffer_size 128k;
            fastcgi_intercept_errors on;
            fastcgi_read_timeout 120s;
            #include naxsi.d/wordpress/*.conf;
        }
        #include naxsi.d/wordpress/*.conf;
    }

    location ~ [^/]\.(php|html)$ {

        fastcgi_split_path_info ^(.+?\.php)(/.*)$;
        if (!-f $document_root$fastcgi_script_name) {
                return 404;
        }
        #fastcgi_pass 127.0.0.1:9000;
        fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
        fastcgi_buffers 256 128k;
        fastcgi_buffer_size 128k;
        fastcgi_intercept_errors on;
        fastcgi_read_timeout 120s;

        set $do_not_cache 1; ## page cache
        set $device "pc";

        if ($request_method = POST) {
            set $do_not_cache 1;
        }

        if ($query_string != "") {
            set $do_not_cache 1;
        }

        if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in") {
            set $do_not_cache 1;
        }

        if ($request_uri ~* "(/wp-admin/|/xmlrpc.php|/wp-(app|cron|login|register|mail).php|wp-.*.php|/feed/|index.php|wp-comments-popup.php|wp-links-opml.php|wp-locations.php|sitemap(_index)?.xml|[a-z0-9_-]+-sitemap([0-9]+)?.xml)") {
            set $do_not_cache 1;
        }

        if ($http_user_agent ~* " Android |\(iPad|Android; Tablet; .+Firefox") {
            set $device "tablet";
        }

        if ($http_user_agent ~* " Android .+ Mobile |\(iPhone|\(iPod|IEMobile|Android; Mobile; .+Firefox|Windows Phone") {
            set $device "smart";
        }

        fastcgi_cache        wpcache;
        fastcgi_cache_key    "$device:$request_method:$scheme://$host$request_uri";
        fastcgi_cache_valid  200 10m;
        fastcgi_no_cache     $do_not_cache;
        fastcgi_cache_bypass $do_not_cache;

        add_header X-F-Cache $upstream_cache_status;
        add_header X-Signature KUSANAGI;
        #include naxsi.d/wordpress/*.conf;
    }

}

デフォルトの http.conf で一旦試してます。

現象

wordpressをサブディレクトリにして、特定のリンクを踏んだら、別のディレクトリを読み込むような設定をやっている最中突然エラーログが出なくなりました。

というより、そのリンクを踏んだ時だけエラーが出ずに詰んでました。

解決策

エラーの log levelが原因でした。

## default HTTP
server {
    listen       80;
    server_name  default_server;
    access_log  /home/kusanagi/wordpress/log/nginx/access.log main;
    error_log   /home/kusanagi/wordpress/log/nginx/error.log debug;
    index  index.php index.html index.htm;

    charset UTF-8;
    client_max_body_size 16M;
・
・
・

log level を一番下の debugにしてみたら noticeが表示された。

これでやっと前に進めそうです。

最後に

ログの出力先に全く問題がないときにはログレベルを疑いましょう(超反省)。

ポケットリファレンスは小さくてマジで便利ですね。おすすめです。

【雑記】ちょっと暇だったのでvimでtwitterできるようにした

f:id:rdwbocungelt5:20180830165411p:plain

どうもってぃです。

VimTwitterをできるようにしました。

有名なTwitVimをインストールしたのでその手順を公開。

環境

  • elementary OS 0.4.1 Loki ( Ubuntu 16.04.5 )
  • curl 7.47.0 (x86_64-pc-linux-gnu)
  • OpenSSL 1.0.2g 1 Mar 2016

TwitVimをインストール

以下のリンクが最新のTwitVimです。

https://www.vim.org/scripts/download_script.php?src_id=23560

一応ここ(https://www.vim.org/scripts/script.php?script_id=2204)で最新がどれか確認してファイルをダウンロードしてください。

今回はtwitvim-0.9.1.vmbをダウンロードします。

ファイルをダウンロードしたら、vimtwitvim-0.9.1.vmbを開きます。

$ vim ~/Downloads/twitvim-0.9.1.vmb

開いたら、:so %でインストール。

僕の場合パッケージはNeoBundleでなくdein.vimです。一瞬で終わりました。

TwitVimの設定と認証

自分のアカウントにログインするためにTwitVimで認証をする必要が有ります。

その際に開くブラウザを指定するのとちょっとした設定を.vimrcへ記載します。

 " vimでtwitter 
 let twitvim_enable_python = 1 
 let twitvim_browser_cmd = 'google-chrome' 
 let twitvim_force_ssl = 1 
 let twitvim_count = 40

twitterSSLじゃないとアクセスできないみたいですね。

なのでtwitvim_force_sslを有効にしてます。

またtwitvim_browser_cmdでブラウザ指定をします。

今回はubuntuベースのelementaryOSでやっているので、google-chromechromeを指定してます(ターミナルでgoogle-chromeと打てば開いたので指定したらうまくいった)。

りんごさんや窓くんは別の指定方法があるようなのでggrk

上記を記載したら、:so ~/.vimrcで設定を反映。 :SetLoginTwitterとタイプすると、chromeが開いて認証画面が出てきます。

認証を完了すると、PINコードが出てくるのでターミナル上に打ち込むとTwitVimでの認証が終わります。

Let's enjoy twitter life !!

仕事をしてるふうにtwitterをしましょうbbbbbbbbbbbbbbbbbbbbbbbbbb





【Linux】シェルスクリプトで親ディレクトリのパスを取得する

上の参考書と以下の記事を参考にさせていただきました。

qiita.com

なぜ調べたか

/home/user/practice/text/test.txt, /home/user/practice/shell/directory.shがある前提で進めます。

#!/bin/bash

PATH=../text/test.txt
echo `head -n 10 $PATH`

これを実行すると...

$ ./directory.sh
./test.sh: 行 4: head: コマンドが見つかりません

となる。

親のディレクトリ指定がよくないみたい。

解決

結論を言えば超簡単。

#!/bin/bash

CURRENT_DIRECTORY=$(cd $(dirname $0); pwd)
DIR_NAME=$(dirname ${CURRENT_DIRECTORY})

echo `head -n 10 $DIR_NAME/text/test.txt`

dirname <カレントディレクトリ>で親ディレクトリのパスを取得できます。

30分くらい詰まった。


【gloudコマンド】ファイアーウォール ルールへ複数IPを設定するシェルを作った

f:id:rdwbocungelt5:20180727094804j:plain

どうもてぃです。

ちょっと前に書いた記事でファイアーウォールルールを20個弱作成しました。

smot93516.hatenablog.jp

確認しながらだったので1時間弱の工数

これをプロジェクト毎に同じ量作成していくって考えるとおぞましい。まじで。

本来なら別プロジェクトでもファイアーウォールルールを共有できたらと思っていろいろ調べてたのですが、よーわからんかったので今回の方法に落ち着きました。

経緯

GCPへ移行させたとある会社のサーバーへ、1分間に3、 4通の頻度で大量の迷惑メールが届いているとの報告をうけました。

ドメインqq.comです。中国?のメールらしい。

Sendgridの管理画面を見てみるとランダムな数字@qq.comのメールが頻繁にきてました。

f:id:rdwbocungelt5:20180823135754p:plain

アクセスログを見てIPを検索した結果、ほぼすべてがフィリピンからの攻撃。

いままで、中国から攻撃が来てたのでその対策はしてたのですが、盲点でした。

思い込みって怖いですね。

今後もファイアーウォールルールを作るって考えると本当に鬱になりそうだったので、だれでもシェルを叩いて作成でき、GitHubに公開して共有すればみんな幸せになるんじゃなかろうか、ということで作成しました。

準備

ローカルでgloudコマンドが使える環境を作っておいてください。

インストール方法は上の記事に載ってます。

GitHub貼っておくのでcloneしてください。

github.com

README.mdに拙い英語でやり方書いてるので、文章間違えあればプルリクおねがいします。

中国、韓国、北朝鮮、フィリピンのIPを制限

cn-kr-kp-firewall.shが中国、韓国、北朝鮮のIPを制限するシェルです。

philippines-firewall.shがフィリピンのIPを制限するシェル。

また攻撃先があれば随時シェルを追加していきます。

さいごに

本当はもっとシェルスクリプトをうまく使って、.txtを全て整形してgcloudコマンド実行させたかった。

もっと勉強します。

【備忘録】docker exec <container ID> bash -cで怒られた

f:id:rdwbocungelt5:20180816164743p:plain

docker execlsコマンドを打とうとしたらエラーが出たので、備忘録として。

環境

  • Docker 17.12.0-ce, build c97c6d6
  • elementary OS 0.4.1 Loki (ubuntu 16.04.1)

状態

docker psで出てくるのが以下2つです。

$ docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
5f5341ffb035        0f9e103b1a23        "bash"              About an hour ago   Up About an hour                        xenodochial_albattani
402d9d6b0227        ubuntu:16.04        "bash"              About an hour ago   Up About an hour                        gifted_meninsky

一番上のコンテナ内のルートディレクトリを参照したい。

$ docker exec 5f5341ffb035 bash -c 'ls /'
OCI runtime exec failed: exec failed: container_linux.go:296: starting container process caused "exec: \"/bin/bach\": stat /bin/bach: no such file or directory": unknown

だめっぽい。

bashディレクトリをちゃんと指定してあげても・・・

$ docker exec 5f5341ffb035 /bin/bash -c 'ls /'
OCI runtime exec failed: exec failed: container_linux.go:296: starting container process caused "exec: \"/bin/bach\": stat /bin/bach: no such file or directory": unknown

だめですね。

解決

stackoverflow.com

これですね。

docker execのオプションが足りなかった模様。

docker exec -i 5f5341ffb035 bash -c 'ls /'
bin
boot
dev
etc
home
lib
lib64
media
mnt
opt
proc
root
run
samplefile
sbin
srv
sys
tmp
usr
var

わざわざコンテナの中に入らずとも無事参照できました。

おわりに

dockerのロゴ使用に決まりとかあったんですね。

みなさんも気をつけましょう。

www.docker.com

【Linuxコマンド】特定のファイルを削除する

f:id:rdwbocungelt5:20180919135208j:plain

どうもってぃです。

サーバー移行している時に不要なファイルが大量に出てきたので全検索削除を行いました。

そんときのメモがこちら。

ディレクトリ配下該当ファイル全削除

$ find . -name '.htaccess' | xargs rm -f

apacheからnginxへ移行するときに不要になる.htaccessファイルがどのディレクトリにもあったので、上記のコマンドで削除しました。

くっそ邪魔な.DS_Store

$ find . -name '.DS_Store' | xargs rm -f

これでおk。

lsとgrepを使う

今いるディレクトリの.txtファイルを全て削除したい場合

$ ls | grep .txt | xargs rm

ディレクトリ配下全ての.txtを削除したい場合

$ find . | grep .txt | xargs rm -f

今回サーバー移行で大量にあったのががファイル名に入っているもの。

エンジニアでなければ前のファイルはバックアップを取らずにという文字列を頭につけてそのまま残しておくみたい。

いと愚かなり。

$ find . | grep 旧 | xargs rm -f

いらないものは削除しましょう。

終わりに

find . -name 'ファイル名'find . | grep hogeも、どれもそうですが、削除する前に一度検索かけて、該当するものが出てきているか確認してから削除しましょう。

いきなり削除してしまって、ああ削除したらいけんやったのにぃ〜となっても知りませんよ。

くれぐれも、気をつけてくださいね。

番外編

nginxのプロセスを全て削除したい場合

$ ps aux | grep [n]ginx | awk '{ print "kill -9", $2 }'