タグ

ブックマーク / qiita.com/kawaz (10)

  • Bashでコマンドの存在チェックはwhichよりhashの方が良いかも→いやtypeが最強→command -vも - Qiita

    コマンドのパスを知りたいんじゃなく、コマンドの存在をチェックしたいだけならwhichよりhashを使ったほうが良いかもっていう話。→追記: typeが最強っぽい。 追記: command -vも良い。プログラムの存在チェックorパスを探したいだけなら互換性を考えると一番良いかも。 比較してみる whichよりhashよりtype=command -vが高速→typeまたはcommand -vの勝ち whichは実ファイルという実体があるプログラムです。hashとtypeはbashの組み込みコマンドです。なので当然ですがプログラムの起動コストがない分hashやtypeの方が速いです。 $ time bash -c 'for((i=0;i<10000;i++));do which perl; done >/dev/null' real 0m7.739s user 0m2.928s sys 0m

    Bashでコマンドの存在チェックはwhichよりhashの方が良いかも→いやtypeが最強→command -vも - Qiita
    oppara
    oppara 2016/09/23
  • glibcの脆弱性対策(取り急ぎiptables/firewalldで叩き落とす!)for CVE-2015-7547 - Qiita

    glibcの脆弱性対策(取り急ぎiptables/firewalldで叩き落とす!)for CVE-2015-7547LinuxSecurityiptablesfirewalldglibc はじめに glibcでヤバメな脆弱性キター! 「glibc」ライブラリに脆弱性、Linuxの大部分に深刻な影響 - ITmedia エンタープライズ Google Online Security Blog: CVE-2015-7547: glibc getaddrinfo stack-based buffer overflow CVE-2015-7547: Critical Vulnerability in glibc getaddrinfo - SANS Internet Storm Center Carlos O'Donell - [PATCH] CVE-2015-7547 --- glibc ge

    glibcの脆弱性対策(取り急ぎiptables/firewalldで叩き落とす!)for CVE-2015-7547 - Qiita
    oppara
    oppara 2016/02/22
  • CORSリクエストでクレデンシャル(≒クッキー)を必要とする場合の注意点 - Qiita

    クレデンシャルの送信 クロスオリジンのAJAXリクエストでクレデンシャル(クッキーの送信またはBASIC認証)を必要とする場合は、それを許可するオプションをフロント側Javascriptで付けておく必要があります。デフォルトではCORSリクエストでクッキーは送信されませんし、BASIC認証は送れません。 Fetch API の場合 fetch(url, { mode: 'cors', //クロスオリジンリクエストをするのでCORSモードにする credentials: 'include' //クレデンシャルを含める指定 })

    CORSリクエストでクレデンシャル(≒クッキー)を必要とする場合の注意点 - Qiita
    oppara
    oppara 2016/02/13
  • XHR2でサブドメインのワイルドカードOriginに対してCORSを許可する設定、他。 - Qiita

    はじめに 今どきのブラウザはではルールに従うことでクロスドメイン(クロスオリジン)のAJAXが出来ます。ルールというのは最低限、AJAXで取得するデータがある先のサーバがAccess-Control-Allow-Originヘッダを返すことです。 ただしこの仕様には関連ヘッダがやたら沢山あるので、やりたいことにたいして適切な設定するには記事後半の関連ヘッダまとめまで目を通しておくことをおすすめします。 単純なケースの .htaccess による設定例(オリジンの許可例) これらの設定サンプルは認証を必要としないシンプルなGETリクエストでCORSを行う為の設定です。 全て許可 一番簡単なのは以下のような設定です。これを .htaccess ファイルに書いておけばそのサイト上のコンテンツは他サイトから取得し放題ということになります。

    XHR2でサブドメインのワイルドカードOriginに対してCORSを許可する設定、他。 - Qiita
    oppara
    oppara 2016/02/13
  • AngularJSのDIの仕組み、minify対策は覚えておこう! - Qiita

    DI (Dependency Injection)ってのは日語では依存性注入とも呼ばれ、大雑把に言うとAngularJSがコントローラなどに必要とされているコンポーネント(オブジェクト)をいい感じに渡してやる機能です。 ここでは特にAngularJSのDIがどのような仕組で動いてるか、そしてその独特なDIの実装にまつわるトラブルケースを説明します。 AngularJSのコントローラの書き方 まずはAngularJSの中心的な機能であるコントローラの書き方には、簡単版と面倒版の複数の書き方があることを抑えておきましょう。 パターン1(グローバル関数パターン) サンプルとかでよく見るのは↓こういうグローバル関数の形のコントローラです。

    AngularJSのDIの仕組み、minify対策は覚えておこう! - Qiita
    oppara
    oppara 2016/01/06
  • 最強のSSH踏み台設定 - Qiita

    追記:openssh-7.3 以降なら ProxyJump や -J が使えます ホスト名を + で繋げることで多段Proxy接続も簡単に、がコンセプトだったエントリの設定ですが、OpenSSH 7.3 から ProxyJump という設定が使えるようになったので、使えるなら ProxyJump を使う方が健全だし柔軟で使い勝手も良いのでそちらを覚えて帰ることをオススメします。 使い方は簡単で以下のような感じです。多段も行けるし、踏み台ホスト毎にユーザ名やポート番号を変えることも出来ます。 # 1. bastion.example.jp -> internal.example.jp ssh -J bastion.example.jp internal.example.jp # 2. bastion.example.jp -> internal.example.jp -> super-de

    最強のSSH踏み台設定 - Qiita
    oppara
    oppara 2016/01/06
  • VMイメージ内でMACアドレスとインターフェース名(eth0とか)の関係が固定化されるのを防ぐ - Qiita

    今時のLinuxはudevが親切にもネットワークインターフェース名とMACアドレスの関係を固定化してくれるんだが、この機能って同じディスクイメージの複製が使いまわされることが前提の仮想マシンを前提にすると非常に邪魔になる。具体的にはコピーしたイメージ上ではeth0が出来なかったり、eth1になっちゃったりとか…。 このMACアドレスの固定化設定は/etc/udev/rules.d/70-persistent-net.rulesというファイルにシェルスクリプトして保存されている。なのでこれを削除してやれば次回起動時は期待通りにeth0が使えるようになる、のだがその際にまたこのファイルが再生成されてしまうので非常に邪魔! というわけでVMイメージの場合は消すだけじゃなく、以下のようにファイルが出来るべき場所にディレクトリを作っておくことでファイル作成が出来ないようにして防ぐってことをしている。

    VMイメージ内でMACアドレスとインターフェース名(eth0とか)の関係が固定化されるのを防ぐ - Qiita
    oppara
    oppara 2015/05/03
  • SSHのknown_hostsをスマートに更新する - Qiita

    今時のバージョンのOpenSSHではknown_hostsがハッシュ化されてて手動管理がしにくいし、スマートに決めたいのでコマンドでやってみる。 コマンド 結論から書くと↓こんな感じでOK。(target-hostnameのホストキーが変わった場合の例) host="target-hostname" ssh-keygen -R $host ssh-keyscan -H $host >> ~/.ssh/known_hosts ssh-keygen -R hostname は ~/.ssh/known_hosts から対象ホストホストキーを削除してくれる。 複数あれば全部消してくれるしハッシュ化されてるのもされてないのも全部消してくれるので便利。 known_hostsファイルをエディタで開いてエラーメッセージで指摘された行数まで移動して手で削除するのなんかより100倍楽。 ssh-keys

    SSHのknown_hostsをスマートに更新する - Qiita
    oppara
    oppara 2014/09/20
  • S3の料金体系が分かりにくいと聞かれたので纏めた - Qiita

    課金ポイントは3つ そんなに難しいことはないと思いますが 課金ポイントは3つ あります。 ストレージ容量 単純に保存容量に対して課金されます。 低冗長化ストレージを指定すると2割くらい安くできます。 ログだとか家族写真の保存だとかメインだとデータ転送よりここにお金がかかってきます。(容量でかいけど古いやつは殆どアクセスしないようなのはライフサイクル設定でGlacierに移動する手もあります) データ転送 課金されるのは(S3からの)送信だけです。受信(S3へのアップロード)は無料です。 また、インターネットへの送信と別のAWSリージョンまたはCloudFrontへの送信で別料金が設定されてますが、小~中規模のシステムならサーバ群は1リージョンに纏まってることが多いでしょうから、CroudFront利用時くらいにしかその料金は発生しないと思います。しかもCroudFront利用時は殆どのトラ

    S3の料金体系が分かりにくいと聞かれたので纏めた - Qiita
    oppara
    oppara 2014/05/28
  • 既存プロセスの標準出力と標準エラーを奪う - Qiita

    #!/bin/bash # 既存プロセスの標準出力と標準エラーを奪う https://qiita.com/kawaz/items/96af6fa59fdf999b94bd # ターゲットのPID pid=$1 [[ -d /proc/$1/fd ]] || exit 1 # 出力先はttyやファイルを指定 out="$2" # 出力先の指定がない場合は現在のttyを出力先にする if [[ -z $out ]]; then # プロセスに紐付いたttyを取得する https://qiita.com/kawaz/items/bd33fe1e29876939dddb function search_tty() { local pid=${1:-$$} tty="" while [[ 1 -lt $pid ]]; do [[ -d /proc/$pid/fd ]] || break tty=$(

    既存プロセスの標準出力と標準エラーを奪う - Qiita
    oppara
    oppara 2014/02/19
    Linux - 既存プロセスの標準出力と標準エラーを奪う - Qiita
  • 1