【Linuxコマンド】特定の文字列を含むファイルを検索する
こんにちはもてぃです。
前のエントリも合わせて記事にします。
特定の文字列を検索して、文字列置換まで合わせてやりたいと思ったので備忘録として。。。
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
あとはxargs
とsed
を使って、文字列を置換してやればおkって感じです。
以下はSSL化の際のhttpをhttpsへ置換するコマンド。
# カレントディレクトリ配下全てのファイルのhttpをhttpsへ置換 $ grep -rlw . -e 'https' | grep html | xargs sed -i -e 's/http:/https:/g'
終わりに
以下の記事を参考に致しました。
ありがとうございます。
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できるようにした
どうもってぃです。
有名な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
をダウンロードします。
ファイルをダウンロードしたら、vimでtwitvim-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
twitterはSSLじゃないとアクセスできないみたいですね。
なのでtwitvim_force_ssl
を有効にしてます。
またtwitvim_browser_cmd
でブラウザ指定をします。
今回はubuntuベースのelementaryOSでやっているので、google-chrome
でchromeを指定してます(ターミナルでgoogle-chrome
と打てば開いたので指定したらうまくいった)。
りんごさんや窓くんは別の指定方法があるようなのでggrk
上記を記載したら、:so ~/.vimrc
で設定を反映。 :SetLoginTwitter
とタイプすると、chromeが開いて認証画面が出てきます。
認証を完了すると、PINコードが出てくるのでターミナル上に打ち込むとTwitVimでの認証が終わります。
Let's enjoy twitter life !!
仕事をしてるふうにtwitterをしましょうbbbbbbbbbbbbbbbbbbbbbbbbbb
【Linux】シェルスクリプトで親ディレクトリのパスを取得する
上の参考書と以下の記事を参考にさせていただきました。
なぜ調べたか
/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を設定するシェルを作った
どうもてぃです。
ちょっと前に書いた記事でファイアーウォールルールを20個弱作成しました。
確認しながらだったので1時間弱の工数。
これをプロジェクト毎に同じ量作成していくって考えるとおぞましい。まじで。
本来なら別プロジェクトでもファイアーウォールルールを共有できたらと思っていろいろ調べてたのですが、よーわからんかったので今回の方法に落ち着きました。
経緯
GCPへ移行させたとある会社のサーバーへ、1分間に3、 4通の頻度で大量の迷惑メールが届いているとの報告をうけました。
ドメインはqq.com
です。中国?のメールらしい。
Sendgridの管理画面を見てみるとランダムな数字@qq.com
のメールが頻繁にきてました。
アクセスログを見てIPを検索した結果、ほぼすべてがフィリピンからの攻撃。
いままで、中国から攻撃が来てたのでその対策はしてたのですが、盲点でした。
思い込みって怖いですね。
今後もファイアーウォールルールを作るって考えると本当に鬱になりそうだったので、だれでもシェルを叩いて作成でき、GitHubに公開して共有すればみんな幸せになるんじゃなかろうか、ということで作成しました。
準備
ローカルでgloudコマンドが使える環境を作っておいてください。
インストール方法は上の記事に載ってます。
GitHub貼っておくのでcloneしてください。
README.mdに拙い英語でやり方書いてるので、文章間違えあればプルリクおねがいします。
中国、韓国、北朝鮮、フィリピンのIPを制限
cn-kr-kp-firewall.sh
が中国、韓国、北朝鮮のIPを制限するシェルです。
philippines-firewall.sh
がフィリピンのIPを制限するシェル。
また攻撃先があれば随時シェルを追加していきます。
さいごに
本当はもっとシェルスクリプトをうまく使って、.txtを全て整形してgcloudコマンド実行させたかった。
もっと勉強します。
【備忘録】docker exec <container ID> bash -cで怒られた
docker exec
でls
コマンドを打とうとしたらエラーが出たので、備忘録として。
環境
- 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
だめっぽい。
$ 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
だめですね。
解決
これですね。
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のロゴ使用に決まりとかあったんですね。
みなさんも気をつけましょう。
【Linuxコマンド】特定のファイルを削除する
どうもってぃです。
サーバー移行している時に不要なファイルが大量に出てきたので全検索削除を行いました。
そんときのメモがこちら。
ディレクトリ配下該当ファイル全削除
$ 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 }'