それマグで!

知識はカップより、マグでゆっくり頂きます。 takuya_1stのブログ

習慣に早くから配慮した者は、 おそらく人生の実りも大きい。

certbot でステージング(テスト環境)用に証明書を作る

certbot で同一ドメインの証明書を複数作る

ステージングや、certbot のコマンドであれこれ実験していると、証明書の発行上限に達してしまいます。

そこで、 ステージング用の証明書を使うと良さそうなので試してみた。ステージングやテスト用にドメインを作って管理するのも面倒な話ですし。

ステージングの使用

testing:
  The following flags are meant for testing and integration purposes only.

  --test-cert, --staging
                        Use the staging server to obtain or revoke test
                        (invalid) certificates; equivalent to --server https
                        ://acme-staging-v02.api.letsencrypt.org/directory
                        (default: False)

ステージングを使うと、閾値による制限にかからなくなるので、コマンドや.gitlab-ci.yml や .circle-ci.yaml に組み込むとき実験で使える。重宝する

使い方

いつもの、certbot のコマンドにオプションを付けるだけ。

  --staging \   を追加しています。

certbot で証明書作るサンプル

mydomain=example.com \
sudo ./certbot-test/bin/certbot  \
  certonly \
  --staging \ 
  --cert-name ${mydomain}-staging \
  --dns-cloudflare --dns-cloudflare-credentials /etc/letsencrypt/cloudflareapi.cfg \
   -d "*.${mydomain}" \
   -d ${mydomain}

わたしは、ドメイン所持のチェックにcloudflare プラグインを使うのでオプションが入っていますね。

実際にアクセスしてみる

証明書のの検証には失敗する。自己証明書よりは簡便でマシかな程度のステージング証明書になる。 f:id:takuya_1st:20190327162607p:plain

削除したり 更新したり

削除したり、更新したり、いろんなcertbot のコマンドを試せたり、また検証サーバーやテスト用に作れるので便利かもしれない。

追記:revoke

--staging / --test-cert で作った証明書は、当然ですが、そのままでは通常運用出来ない代物なので、 revoke する必要がなく、revoke コマンドは通りません。

不要になったら delete します。

その他の方法

dry-run の利用

dry-run でも似たような効果は得られる。

--dry-run             Perform a test run of the client, obtaining test
                        (invalid) certificates but not saving them to disk.
                        This can currently only be used with the 'certonly'
                        and 'renew' subcommands. Note: Although --dry-run
                        tries to avoid making any persistent changes on a
                        system, it is not completely side-effect free: if used
                        with webserver authenticator plugins like apache and
                        nginx, it makes and then reverts temporary config
                        changes in order to obtain test certificates, and
                        reloads webservers to deploy and then roll back those
                        changes. It also calls --pre-hook and --post-hook
                        commands if they are defined because they may be
                        necessary to accurately simulate renewal. --deploy-
                        hook commands are not called. (default: False)

参考資料

https://certbot.eff.org/docs/using.html?highlight=staging

Certbot で証明書を削除する。

Certbot で証明書を消す

選択した証明書を消すには、対話式CLIを使うのが楽

sudo certbot delete 

f:id:takuya_1st:20190327153208p:plain

証明書の名前(ドメイン)がわかっているとき。

証明書の名前を指定して、オプションで明示することで削除ができる。

sudo certbot delete --cert-name example.com

---cert-name は自分で自由に決められる名前ですが、だいたいみんなドメインを使います。 わたしは使ってませんが。。。

その他の方法

直接ファイルを消すという手もあるにはある。

rm -rf /etc/letsencrypt/live/${DOMAIN}
rm /etc/letsencrypt/renewal/${DOMAIN}.conf

revoke して無効化することもある。

delete ではなくrevoke して一旦無効化することもいい。certbot は revoke すると その後 delete するらしいです。

Once a certificate is revoked (or for other certificate management tasks), all of a certificate’s relevant files can be removed from the system with the delete subcommand:

コレを読む限り、delete するより、revoke のほうが良さそうですね。

参考資料

https://certbot.eff.org/docs/using.html?highlight=revoke

mac のnetworksetup コマンドでVLAN作成

Mac のVLAN作成をCLIでコマンドからやる。

コマンドライン(CLI)で、VLANネットワークの設定をやる

networksetup コマンドでVLANインターフェースを作る。

コマンドとしてVLANを扱うのは次の通り。

networksetup -createVLAN <VLAN name> <parent device name> <tag>
networksetup -deleteVLAN <VLAN name> <parent device name> <tag>
networksetup -listVLANs
networksetup -listdevicesthatsupportVLAN

VLANが作れるデバイスには制限がある。

VLAN作成可能なネットワーク・インターフェースには制限がある。 実NICを接続する必要があった。

最初に、VLAN作成可能なデバイスを調べる。

takuya@~$ networksetup -listdevicesthatsupportVLAN

en21 (AX88179 USB 3.0 to Gigabit Ethernet)

VLAN を作る

networksetup -createVLAN test en21 200

作成できる。結果は何も表示されない。

エラー時はエラーが表示される。

たとえば、作成ができないデバイスWi-Fi)に対してVLAN ID を作成しようとすると

takuya@~$ networksetup -createVLAN test en0 2000
Could not find VLAN capable hardware port or device named en0.
** Error: The parameters were not valid.

このようにエラーが出る。

 作成結果を確認する。

createVLANコマンドでは結果が表示されないので、一覧コマンドで作成結果を確認する。

networksetup -listVLANs

コマンドでカクニンすることができる。

実例

takuya@~$ networksetup -listVLANs

VLAN User Defined Name: test
Parent Device: en21
Device ("Hardware" Port): vlan0
Tag: 200

ここで、vlan0 として作られたことがわかる。

実際にvlan0 があることを調べる。mac なので ifconfig ですね。

takuya@~$ ifconfig  vlan0
vlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    options=3<RXCSUM,TXCSUM>
    ether 00:00:68:ab:47:71
    nd6 options=201<PERFORMNUD,DAD>
    vlan: 200 parent interface: en21
    media: autoselect (<unknown type>)
    status: inactive
takuya@~$

Mac でVLANのタグを読めるインターフェイスを作成する

mac でもVLANを使いたい。

MacOS のLANインターフェースでVLANを扱う必要があった。ぱぱっと設定したときにどうやったかメモを残しておきます。

VLAN は環境設定から。

環境設定のネットワークをひらく。 左下の歯車のアイコンを押す。(ここがポイント) f:id:takuya_1st:20190322135718p:plain

仮想インターフェイスを作成を選ぶ。

メニューの中から、仮想インターフェイス管理を選ぶ。

f:id:takuya_1st:20190322135723p:plain

VLAN作成を選ぶ

仮想インターフェイスの一覧が表示されるので、左下の追加(+)ボタンを押す。
新規VLANを選びます、

f:id:takuya_1st:20190322135727p:plain

VLANを作成します。

VLAN ID と インターフェース、インターフェース名を入力します。

f:id:takuya_1st:20190322135732p:plain

疎通を確認します。

あとは、VLANネットワークとの疎通を確認します。

一般のご家庭で手軽にVLANして遊ぶには

VLANって逸般の誤家庭にはあるけど、一般のご家庭には無いんですよね。

ところが、次のような2500円程度の機材を使うことで、手軽にVLANを張って遊べます。便利。

ip コマンドでルーティングテーブルの逆引き(?)どのルートを通るか調べる

ip route show してもすっとわからない。

このIPはどのルーティグで転送されるの??

ip route show してもわからない、僕ら素人のためのコマンド

ip route get

宛先IPアドレスを指定すると。そのIPアドレスはどのルーティングテーブルにマッチするのかを調べることができる。

使用例

takuya@Desktop$ ip route get 192.168.2.1
192.168.2.1 via 192.168.11.1 dev en7  src 192.168.11.141

ipv6 で役に立つ。

IPv6 だと一目で即時にルーティングが見えづらい。アドレスが長いので、一呼吸を置いてから脳内で整理してたけど。 このコマンドを使えばそういうの面倒な脳内処理が不要になる。

ルールが複雑なときや、ルーティング順番がうまくマッチしないときに、どのrouteがマッチするのか調べることができるから便利。

使用例

takuya@:~$ ip route  get 2001:xxxx:38a8:3700:e80:63ff:xxxx:xxse
2001:xxxx:38a8:3700:e80:63ff:xxxx:xx3b from :: via fe80::225:36ff:fe75:a542 dev vlan2 
proto ra src 2001:axxx:8383:a300:b1a2:9557:xxxx:xxa4 metric 400 pref medium

もっとはやく教えてくれよ。

curl-config 現在のcurl のコンパイル設定を知るコマンド

brew 整理してたら curl-config コマンドを見つけた

curl-config コマンドってなんだろう。

調べてみると。インストール(ビルド)されているcurl のビルド状況を把握するシェルスクリプトらしい

実行してみた

takuya@Desktop$ curl-config --libs
-L/usr/local/Cellar/curl/HEAD-9e6af11/lib -lcurl -lidn2 -lrtmp -lldap -lbrotlidec -lz
takuya@Desktop$ curl-config --version
libcurl 7.64.1-DEV
takuya@Desktop$ curl-config --feature
SSL
IPv6
UnixSockets
libz
brotli
AsynchDNS
IDN
NTLM
NTLM_WB

なるほど。僕のhomebrew の curl は HEAD でv6 とhttp2 を有効にしているからcurl-config もインストールされていたわけですね。

参考資料

https://curl.haxx.se/libcurl/using/curl-config.html

bash で mac かどうかを判定する

mac かどうかをbash のif文の条件判定する

[[ $(uname) =~ Darwin ]]; echo $?
## または
[[ $(uname -a ) =~ Mac ]]; echo $?

bash正規表現ってホント便利

正規表現を使わない場合

bash 以外と bash 3.2 未満は正規表現が使えないので、glob でマッチする

[[ $(uname -a) = Darwin* ]]; echo $?

関連資料

bashでif に正規表現を使った文字列マッチ条件分岐 - それマグで!

neovim で python3 の環境を安定的に運用するために pyenv/virtualenev 化した。

neovim と pyenv が同時にあると困る。

pyenv で version を切り替えた後に neovim を使おうとすると python3 系のpip モジュールが見つからなくて困る。

問題をもうちょっと詳しく

次のような状態になると、neovim がpython3 ネーヨ。とエラーになる。

pip install X.x.x
pip local X.x.x
nvim /path/to.py ##  動くには動くがneovim モジュール見つからない

原因と経緯

なんでこんな事が起きるのか。

  1. neovim でアレコレするには python3 が必要 ( pip install neovim )
  2. python3 は pyenv で管理されている。
  3. pyenv でバージョンを切り替える。
  4. pyenv local / virtualenv 環境下に pip install neovim しないと neovim がエラーになる

python3とneovim のプラグインを諦めて使うしないかなという解決策で凌いでいたが限界。

pyenv install に neovim.egg を入れていたけどそれも面倒。

解決策 neovimが virtualenv を使えばいいんだ。

nvim 側が、virtualenv のpython3を使えばいいんだと気づく。

neovim 専用の virtualenv を作り、nvim は init.vim で virtualenv を参照すればいい。

やりかた

pyenv を使って nvim 専用の virtualenv を作る。

必要なものをインストール

さいしょに、必要になるvenvを用意する。

pyenv と pyenv-virtualenv は brew でぱぱっと入れた。

brew install pyenv pyenv-virtualenv

venv を準備する。

pyenv virtualenv 3.7.2 nvim-python3
pyenv activate nvim-python3
pip install neovim

nvim 側が venv を使うようにする。

nvim 側でシェルから渡される $PYENV_ROOT の環境変数を用いて、python3 を指し示す。

~/config/neovim/init.vim

~/config/neovim/init.vim または ~/config/nvim/init.vim

"" for only neovim. in pyenv virtualenv named 'nvim-python3'
if has('nvim') && isdirectory( $PYENV_ROOT."/versions/nvim-python3" )
  let g:python3_host_prog = $PYENV_ROOT.'/versions/nvim-python3/bin/python'
endif

私は、設定をvim/neovim で適当にコピペで使いまわしつつ vimrc を あちこちで使い回せるように if 文を入れました。

最後に :checkheath

:checkhealth

f:id:takuya_1st:20190312174206p:plain

まぁ、起動するとエラーならなきゃOKですが。念の為。

コレの設定による効果

pyenv 切り替え後で neovimが壊れるとか気にしなくていいんです。

更新やインストールに対する心理的負荷が大幅に軽減されました。

まとめ

Python2.x 系のサポートを有効にする。

pyenv virtualenv 2.7.17 nvim-python2
pyenv activate nvim-python2
pip install --upgrade pip
pip install  neovim
pipenv which python 

Python3.x系のサポートを有効にする

pyenv virtualenv 3.7.4 nvim-python3
pyenv activate nvim-python2
pip install --upgrade pip
pip install  neovim
pipenv which python 

init.vim に追記する。

"" for only neovim. in pyenv virtualenv named 'nvim-python2'
if has('nvim') && isdirectory( $PYENV_ROOT."/versions/nvim-python3" )
     let g:python_host_prog = $PYENV_ROOT.'/versions/nvim-python2/bin/python'
endif
"" for only neovim. in pyenv virtualenv named 'nvim-python3'
if has('nvim') && isdirectory( $PYENV_ROOT."/versions/nvim-python3" )
     let g:python3_host_prog = $PYENV_ROOT.'/versions/nvim-python3/bin/python'
endif

バージョン番号は好きな番号でいい。

2019-05-17

パス修正

2020/08/15

python2 のバージョン使って、インストールしないと Deopleteがエラーになったので追記。

2021/05/18

pyenv virtualenv のインストールについて追記

参考資料

PHP Fatal error: Uncaught ErrorException: preg_replace(): JIT compilation failed: になる。

macOS でphp7.3 を homebrew で入れた場合に発生します。

ほんと、もうphpは。。。brew にちゃんとしたコンパイル設定を送ってよね。

PHP Fatal error:  Uncaught ErrorException: preg_replace(): JIT compilation failed:

no more memory in phar:///usr/local/Cellar/composer/1.8.4/bin/composer/vendor/symfony/console/Formatter/OutputFormatter.php:36

対症療法

php.ini ファイルに次の行を書き込む。

pcre.jit=0

まぁそのうち治るだろうから、 user.ini を使うといいと思う。私はそうした

だってphp.ini を書き換えたらもとに戻すの忘れそうだもの

真剣に治すとしたら

ビルドオプションを変えてビルドし直し。でしょうか。php7.3 の別バージョンを使うとか。それともphp7.2 を諦めて使うか、まぁソレくらいが無難ですかね。

参考資料

https://stackoverflow.com/questions/53690624/errors-installing-composer-on-macos-jit-compilation-failed

https://bugs.php.net/bug.php?id=77260

tcpdumpで 自分自身のIPへのパケットを見る( locahost / 自分のIP )

自分自身へのパケットをキャプチャする

sudo tcpdump -i lo

tcpdump を使えば、自分から自身の宛のパケット、つまりループバックアドレスへのパケットと、自分自身のIPへのパケットを見ることができる。

自分自身へのパケットとは

localhost 宛のパケット 。 ::1 とか 127.0.0.1 と、自分が持ってる自IPアドレス を指す。

自分自身が持ってるIPへのパケット

たとえば、自分のIPが 192.168.12.34 のとき、

ping 192.168.12.34 

このように自ホストIPから自ホストIPへのパケットの場合も含まれる。

明示したいとき

127.0.0.1/24 を除いて、自ホストIPへのパケットを見るときはこのようにする。

sudo tcpdump -i lo host 192.168.12.34

参考資料

https://stackoverflow.com/questions/3130911/tcpdump-localhost-to-localhost

mysql locahost の接続では、unix socket かTCPかを明示しないとsock エラーで混乱した

ローカルホストのmysql に接続するときに、次のようにすることが多かった。

mysql -h localhost

正直、これでつながってるから、TCPだと思ってた。

でも、繋がらないので驚いた。エラーをよく見るとmysql.sockって書いてある。 あれれTCP/IP接続じゃなーい?

ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)

衝撃の事実。いままでTCPだと思ってたものは unix socketでした。

今日ね、mysql をポート別にdocker で3つ起動てlocalhost側にdocker から公開したんですよ。 つながらないんです。

アレレと思って調べてたら。mysqllocalhost には明示しない限りUNIX ドメインソケットでつなぐんですって。

tcpでつながってると思いこんでたやつ

takuya@:~$ mysql -v -h localhost  
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]>

しかし、実際はTCPではなかった。

なんかうまくつながらない時があると思ってたけど

ERROR 2003 (HY000): Can't connect to MySQL server on 'localhost' (111 "Connection refused")
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)

あれれれれ、つながらない。

ポートを確認してみる。

つながらないからポートを確認してみると閉じてる。

takuya@:~$ sudo nmap 127.0.0.1 -p  3306

Starting Nmap 7.40 ( https://nmap.org ) at 2019-03-11 11:07 JST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000060s latency).
PORT     STATE  SERVICE
3306/tcp closed mysql

Nmap done: 1 IP address (1 host up) scanned in 0.34 seconds

ややこしいので整理する。

これはUNIX SOCK ファイル経由

takuya@:~$ mysql -v -h localhost
[mariadb] Password:

この接続はlocalhost にあるデフォルトのパス位置にある、sock ファイル

接続を調べてみた

## これはTCP
takuya@:~$ mysql -v -h localhost --protocol=TCP
## これはTCPじゃなさそう
takuya@:~$ mysql -v -h localhost -P 3306

これは、ポートを明示しているのでTCPと思いきや、UNIXだった(tcpdump で何も見えない。TCP接続に失敗後にフォールバック??)

localhost 宛のパケットを tcpdump -i lo  で見てたけど、パケットを送ってない。まさかのミステリー。

同一ホスト内でIPしてた場合。

これらは全部TCP

takuya@192.168.11.100:~$ mysql -v -h 192.168.11.100
takuya@192.168.11.100:~$ mysql -v -h 192.168.11.100 -P 3306 
takuya@192.168.11.100:~$ mysql -v -h 192.168.11.100 --port 3306 
takuya@192.168.11.100:~$ mysql -v -h 192.168.11.100 --port 3306 --protocol=TCP

tcpdump -i lo  で見てたけど、パケットが出てきたので、TCPだと思われる。

注意点

この実験をする前に、ユーザの接続権限を確認しておくこと。

mysql> select Host,User from mysql.user;
+-----------+------------------+
| Host      | User             |
+-----------+------------------+
| localhost | mysql.infoschema |
| localhost | mysql.session    |
| localhost | mysql.sys        |
| localhost | root             |
+-----------+------------------+
4 rows in set (0.00 sec)

root@localhost のように、localhost 限定だと、そもそもつながらない。

CREATE USEr 'takuya' identified by 'your pass'
RENAME USER 'takuya'@'localhost' TO 'takuya'@'%';
GRANT ALL PRIVILEGES ON * . * TO 'takuya'@'%';

結論

localhost への mysqlTCP接続(ポートを変えるなど)のとき --protocol=TCP をつける。のが今の所無難っぽい

そして、これはドキュメントを読んで、さらに調査が必要。

xml のシンタックスチェックを手早く行うコマンド

xmlシンタックスチェックは、xmllint で

apt install xmllint

だけど、シンタックスチェックがなにもないときに、余計な出力が多すぎる。

XMLシンタックスチェックを手早く行う

xmllint --noout sample.xml

これをすると、OKのときは、「なにもしない」ので、手軽にシンタックスがOKだとわかる。

OKの結果をどうしても結果を知りたいときは

xmllint --noout samplex.ml && echo syntax OK

関連資料

php/php-cliでプロジェクト単位(ディレクトリ単位)の設定を.user.iniで読み込ませる。

php でプロジェクト単位の設定を使いたい

php には、ディレクトリ単位で php の設定を変更する user.ini という特殊なファイルを使うことができる。

イメージとしては .htaccess のようなものでディレクトリに設置することでディレクトリ単位でphpの挙動を変更することが可能。

もし仮に、すべての設定を変更できてしまうと、セキュリティホールを作ったり、php自体の動作を変えてしまえるものなので、すべての変更をできるわけではないが。

php で .user.ini ファイルの使い方

プロジェクトのフォルダに、.user.ini ファイルを置いて 、中身はphp.ini の書き方で設定を上書きする。

これだけ。これでで SAPIの mod_php で使える。php-fcgi のような nginx + php-fpm や apache + php-fpm でもつかえるらしい。

で、コマンドのときはどうするの?

環境変数から指定できます。

たとえば、次のようにすると、カレントディレクトリにある .user.ini を読み込ませる事ができます。

PHP_INI_SCAN_DIR=.  php -i 

これは、bashrc などに記述して export することで別プロセスになっても使用可能です。

export PHP_INI_SCAN_DIR=.

実験してみよう

ここで、環境変数から書き換えを実験してみよう。

.php.user.ini ファイルを作る

date.timezone=UTC

指定して実行する。

takuya@ $ PHP_INI_SCAN_DIR=. php -i | grep timezone
Default timezone => UTC
date.timezone => UTC => UTC

何も指定しないとき

takuya@ $ php -i | grep time
Default timezone => Asia/Tokyo
date.timezone => Asia/Tokyo => Asia/Tokyo

.php.user.ini でいいの?

末尾さえ合ってたら、なんとなく読み込んでくれるんですよね。 conf.d の代わりにも使えそうですね。

takuya@ $ PHP_INI_SCAN_DIR=. php -i | grep ini
Configuration File (php.ini) Path => /usr/local/etc/php/7.3
Loaded Configuration File => /usr/local/etc/php/7.3/php.ini
Scan this dir for additional .ini files => .
Additional .ini files parsed => ./.php.user.ini
user_ini.cache_ttl => 300 => 300
user_ini.filename => .user.ini => .user.ini

PHP_INI_SCAN_DIR=. だけで動かないことも (2023-11-06追記)

PHP_INI_SCAN_DIR=.にすると、/etc/php/xxx/cli/php.ini が読み込まれないことがあるので、ちゃんとバージョンごとに設定する

export PHP_INI_SCAN_DIR=/etc/php/8.2/cli/:/etc/php/8.2/cli/conf.d:.

これめんどくさいんですよねぇ。なんかデフォルトで有効にする事できないのかなぁ。

.user.ini ファイルは便利

このように user.ini ファイルで、一時的な設定を記述することが可能である。

便利に使うと、プロジェクト単位で必要な php.ini の設定を .user.ini として管理できるので、TravisCI のような継続的インテグレーションにおける、自動テスト環境のphp.ini ファイルをいちいち書く必要もないし、Dockerfile でアレコレする必要もなくなる。

とりあえずファイルさえアレば動くというphpの良さが顕在化しているのが user.ini の魅力だと思う。

参考資料

https://stackoverflow.com/questions/41496727/how-to-force-php-cli-to-read-my-user-ini-file

ubuntu で vlanを使う( vconfig コマンド編 )/tcpdump でvlan 確認

最初にパッケージを用意する

sudo apt install vlan

タグVLANのためのインターフェース名を用意する

タグを貼り付けるインターフェース名を確認

ip  a
sudo vconfig add enp3s0 4

すると、enp3s0.4の vlan 専用インターフェースが作られる。 この状態では、このインターフェースから出ていくパケットはVLAN ID4が付与されている。

疎通を確認する。

このインターフェースにIPをつける

sudo ip addr add 10.0.0.4/24 dev enp3s0.4

IPが無事付与されたら、パケットを投げつけたいが、そのまえにルートを確認しておく

takuya@:~$ ip route 
default via 192.168.1.1 dev enp3s0 proto dhcp metric 100 
10.0.0.0/24 dev enp3s0.3 proto kernel scope link src 10.0.0.4

疎通確認の前に、経路を確認するのは、IPv4 を触る者の基本的な身だしなみ。

他のVLANマシン(VLANで疎通できるもの。)と通信をする。

ping 10.0.0.1 

疎通確認がとれたらおっけ。パケットが変なとこに行ってないかとかそういうのは、VLAN設定のところになるので割愛

ちゃんとVLANで通信しているかチェックしたいときはtcpdump

tcpdump でVLANのタグを確認できる。

sudo tcpdump -e -n icmp

tcpdump に -e オプションをつけることで、VLAN ID が出力されるので、表示からVLANのパケットをチェックすることができる。このやり方は嬉しい。 f:id:takuya_1st:20211129172404p:plain

参考資料

https://wiki.ubuntu.com/vlan

findコマンドで、実行可能ファイルだけを取り出す(権限・パーミッションで調べる)

find コマンドでパーミッションが実行のものを取り出す。

find $path -type f -executable 

実行可能なファイルを探すときに便利。

コマンドとして実行可能なファイルや、+x として executable の権限を付与されたファイルを探すのに便利。

他の解法

find -perm  755 

permission をそのものを調べる方法もあり。 perm をつければ権限を調べられる。

関連資料

すぐわかるfindコマンドの使い方 - それマグで!

参考資料

https://superuser.com/questions/38981/how-can-i-find-only-the-executable-files-under-a-certain-directory-in-linux