「localhost」を含む日記 RSS

はてなキーワード: localhostとは

2018-12-10

[]2018年12月9日日曜日増田

時間記事文字数文字数平均文字数中央値
0012617429138.339
018715637179.755
02464886106.273.5
03347349216.156
04224164189.349
05173537208.165
06121789149.145
0744333975.933
08597214122.339
09535642106.541
10767994105.239.5
1177672587.334
1287735584.560
13616923113.538
145912106205.239
156223605380.742.5
1669502472.826
171511209080.135
18130847965.237.5
199910441105.539
20788176104.836.5
2195610064.231
2214216071113.237
2320221729107.634
1日1888223804118.538

頻出名詞 ()内の数字単語が含まれ記事

人(165), 自分(157), 今(98), 増田(82), 話(70), あと(59), 必要(58), 好き(55), 感じ(53), 人間(53), 前(51), 仕事(50), 日本(48), 意味(45), 関係(43), 男(42), 女(41), 時間(41), 気(40), ー(38), 普通(38), 相手(38), 子供(38), 今日(37), 問題(37), ネット(36), 絶対(36), 言葉(35), 他(34), 場合(33), 女性(33), 理解(33), 最初(33), 金(33), 嫌(32), 最近(32), 社会(31), 頭(30), 結果(30), 親(30), 理由(30), 目(29), 結婚(28), 全部(28), しよう(28), 無理(27), ダメ(26), 逆(25), たくさん(25), 別(25), 昔(25), 状態(24), じゃなくて(24), 世界(24), お金(24), 気持ち(24), 一番(24), 他人(24), 本人(23), しない(23), 嫌い(23), アニメ(23), 生活(22), 評価(22), ゲーム(22), 男性(22), 時代(22), 存在(21), 体(21), 大事(21), 状況(20), 作品(20), 方法(20), 情報(19), 一人(19), バイト(19), 興味(19), 会社(19), 誰か(19), 努力(19), では(19), 全て(19), レベル(19), クズ(18), 説明(18), 大変(18), 周り(18), 本(18), 人生(18), 全員(18), 家(18), 社員(18), 絵(18), おっさん(18), バカ(18), 結局(18), 文化(18), 映画(17), 経験(17), 自由(17), 塾(17), 勝手(17), 正直(17), オタク(17), 内容(17), 名前(17), 価値(17), 手(17), 病気(17), 朝(17)

頻出固有名詞 ()内の数字単語が含まれ記事

増田(82), 日本(48), じゃなくて(24), 可能性(16), 元増田(13), いない(13), トラバ(12), 多様性(11), キモ(11), スマホ(11), 価値観(10), 自由意志(10), なんの(10), ブログ(10), フランス(10), 東京(10), 2018年(10), ワイ(9), SNS(9), わからん(9), …。(9), なんだろう(9), ネオリベ(9), ブクマ(8), 過労死(8), 基本的(8), アメリカ(8), マウンティング(8), ツイッター(8), なのか(8), 10年(8), 牛丼(8), 普通に(8), イヤホン(8), A(7), 自己肯定感(7), マジで(7), ガチ(7), 自動運転(7), アプリ(7), キチガイ(7), -2(7), a(6), 笑(6), 積極的(6), s(6), いいんじゃない(6), localhost(6), 何度(6), hatena(6), ダイバーシティ(6), 発達障害(6), 涙(6), 個人的(6), OK(6), Ubuntu(6), プレイ(6), イケメン(6), フェミ(5), 1年(5), である(5), とはいえ(5), AI(5), 自己責任(5), ディストピア(5), 自分自身(5), tbsradio(5), 分からん(5), 2017年(5), 書き起こし(5), 2回(5), 若い人(5), 大阪(5), goo.gl(5), ブコメ(5), twitter(5), 関係者(5), 栄光ゼミナール(5), 30分(5), 過去最低(5), 一日(5), paypay(5), Session(5), ウザ(5), マクロン(5), ありません(5), 81%(5), 保護者(5), はてなー(5), 永田(5), ドイツ(5), 1回(5), E3(5), 中国(5), .s(5), 荻上(5), はてブ(4), 至上主義(4), 被害者(4), 学生時代(4), いいね(4), 娘(4), 大企業(4), 人権侵害(4), items(4), AB(4), 自分たち(4), 風俗嬢(4), あいつら(4), KKO(4), 毎日(4), aXvn(4), Windows(4), サイコパス(4), ASD(4), 低能先生(4), にも(4), 関東(4), 人間関係(4), ヒトラー(4), 何回(4), 韓国(4), X(4), いいじゃない(4), qiita(4), 名古屋(4), 2ch(4), 1日(4), アラサー(4), Chrome(4), E(4), 一般的(4), 上の(4), かもしれん(4), 経済的(4), オチ(4), まとめサイト(4), AA(4), あるかな(4), B(4), ゲートウェイ(4), 自己満足(4), 影響力(4), コスパ(4), ラノベ(4), 2時間(4), 上場企業(4)

本日の注目単語 ()内の数字単語が含まれ記事

過去最低(5), 永田(5), 栄光ゼミナール(5), 紅生姜(4), マクロン(5), のこぎり(4), 荻上(5), 絵の具(3), 望(3), 白地(3), パイパイ(3), 自由意志(10), 暴動(8), 塾(17), 過労死(8), 牛丼(8), イノベーション(6), イヤホン(8), 皿(11), ケア(6), ネオリベ(9), 整形(9), 教室(9), 自己肯定感(7), 日曜(6), アクセス(12), そうした(9), 多様性(11), 介護(10), 遠い(8), マウンティング(8), 調査(10), 初期(8), 勤務(10), デート(11), バイト(19), ごめんなさい(8)

頻出トラックバック先(簡易)

過労死を出した栄光ゼミナールがどうなっちゃってんのか書いておく /20181208225303(20), ■ /20181208233617(19), ■ /20181209144856(14), ■『帰ってきたヒトラー』みたいな映画日本で撮るなら /20181208220445(12), ■チャリに乗ってイヤホンは本当に悪いのか? /20181208120626(10), ■結婚を考えてる相手が姓を捨てたくないと言ってきたら /20181208131726(9), ■増田ってひねくれた略称だよね /20181209110804(7), ■整形ってなんで忌み嫌う対象なんだろう? /20181209164235(7), ■「死にたい」にかける言葉 /20181209013103(7), ■尿道がズキズキする /20181209001114(6), ■カップヌードルに水を入れてしまった時の絶望感 /20181208175842(6), ■母はどうにも察しが悪い /20181209120616(5), ■プログラミング勉強ってどうやんの /20181209183335(5), ■漫画原作だけどアニメの方が面白い作品 /20181209000244(5), ■婦人系の病気をどこまで男性上司に伝えるべきか /20181209002118(5), ■窃盗症と自由意志に関する疑問 誰か教えて /20181209233033(4), ■アニメが嫌いなのは声優の演技がうざいから /20181209125120(4), ■石橋容疑者ダイバーシティ /20181208164423(4), ■[勉強] UbuntuWebサーバー構築を断念 /20181209225349(4), ■欧米人ヒトラーを憎んでいる理由がわからない /20181209013347(4), ■乳首の皮膚がボロボロ取れるんだが /20181209234607(4), ■作品タイトルの付け方が分からん /20181209012700(4), ■Wi-Fiはタダで使えると思っている奴多すぎ問題 /20181206214612(4), ■ズブズブの関係 /20181209215113(4), ■もうすぐ大学受験を控えてるんだけど /20181209192410(4), ■やりたいことが出てこない /20181209001258(4), ■犬猫は飯食っただけで褒められる /20181208203002(4)

増田合計ブックマーク数 ()内の数字は1日の増減

5863519(3931)

2018-12-09

anond:20181209225349

localhost」「localhost:8000」にアクセスしても初期ページが表示されない。

VirtualBoxNAT設定してみれ

詳細設定が必要から

2018-07-13

今更El CapitanからHighSierraにしたメモ

httpd.confが初期設定に戻ってた

localhosthttps化してたのだが、OSを入れ直したらオレオレSSLの設定をし直さなきゃいけない

ブラウザ動作確認するときスーパーリロードをしないと、サーバーエラーの表示がキャッシュから表示されて、余計に混乱する

11.0を使ってたのだが、12.0にアップデートしたら、キーボード認識で右シフトの一つ左キーのところで、先に進まなくなる

認識ウィンドウを閉じると、キーボード英語キーボード認識されてしま

これが原因かcomplex_modification.jsonの読み込みでエラーが出る

  • Day-O

2.0にしたら、曜日表示が英語しかできない

よく使う項目の順序がリセットされてて面倒

2016-04-26

anond:20160426124418 続き

プレビューまでは全文見えるんだけどな。すまんやで。しかもまだ続く anond:20160426150324

anond:20160426124418 の続き

おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います特にデスクトップアプリでは、コンパイルされたアプリバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくありますGoogleOAuth の使い方を多数提供しているうちで、client_secret と redirect_uri を両方受け取るエンドポイントのことが書いてあるのはたったひとつだけだというのは重要な点です。少なくとも Google場合、redirect_uri があっても、このエンドポイントウェブブラウザベースアプリには推奨していません。しかし、だからといって実際に独自ブラウザでそれを使う人や、このフロー標準的ブラウザ用のエンドポイントコピーする人が一切いなくなるはずがありません。それに加え、Google例外なのであって、世の中にはセキュアな OAuth フローを受け入れず client_secret (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。

前掲のセキュリティ文書は、アプリ認証情報 (client_id と client_secret) を盗んだ人ができる悪行にいくつか言及しています。以下に、この攻撃と組み合わせることで (これまで筆者の知る限り公表されていない) 危険行為を実行可能にする問題をいくつか取り上げますさらに皆様の独創性にかかれば、「秘密」のはずのものを盗んだ人が悪用できる方法は他にも発見できるはずです。

セキュアでないトークン

トークンベース認証は多くの開発者にとって新しい概念です。そのため誤解も多く、EVS のようなもの設計する開発者の中にも、ただ何かの設計ガイドライン (たとえば OAuth) に従って API の動作を決めれば、あるいは他のプラットフォームのしていることをコピーすれば、自分プラットフォーム自動的にセキュアになるはずだと考える人が少なくありません。しかし何かをセキュアにするには、その要素ひとつひとつを余さずセキュアにする必要があり、それらの組み合わせすべてをセキュアにする必要があり、全体の枠組みもセキュアにする必要があります。思い出してください、全体のセキュリティ強度はその弱点の強度に等しいのですから、何らかの大まかなフレームワークを固守することだけに頼りきって、その通りに使う限り何をやってもセキュアだ、などと安心するわけにはいきません。OAuth ベースフレームワークそれ自体は、その内部要素のセキュリティを確保することに関しては殆ど何もしてくれません (ある種の要素で、あからさまにセキュリティを害するものだけは別)。

トークンベースシステムで少しでもセキュリティらしさを出すには、最低でもトークン生成に暗号学的にセキュアな擬似乱数生成器 (CSPRNG) を使う必要がありますが、この話題はあまりよく理解されていません。さらに悪いことに、一般的スクリプト言語の適切な CSPRNG 用 API は非常に少なく、しかしそうしたスクリプト言語が、人気ある最新サービスの多くを設計する際の基礎となっていることが多いのです。

もし生成されるトークン予測可能であれば、攻撃者はトークンを推測するだけで別のユーザになりきって悪意ある行為をすることができてしまます。筆者は、fortune 500 クラス大企業による OAuth ベースサービス一種の単調増加 ID (おそらくデータベースフィールド?) をそのままトークンに使っているのを見たことがあります。他にも、生成されるトークンがすべて単調関数の出力のようなサービスもありました。よく調べてみると、それは現在時刻に基づく非常に単純なアルゴリズムでした。こうしたシステムでは、まず自分としてログインし、現在トークン ID を見て、その後の ID を予測すれば、続く任意ユーザになりかわってトークン交換その他の操作にそれを使うことができるでしょう。他のテクニックと組み合わせれば、もっと標的を絞った攻撃も可能です。

このクラス攻撃は前述のセキュリティ文書で「4.5.3. オンライン推測による新規トークン取得の脅威」や「4.6.3. アクセストークン推測の脅威」に分類されています。この問題には解決策があるとはいえ、現時点でこの間違いを犯しているサービスの膨大さと、この間違いの犯しやすさを考えると、任意OAuth ベースサービスが外部レビューセキュリティを証明してもらえる可能性はあまり高くありません。

本欄の主眼ではありませんが、乱数に対する攻撃の中には、セキュリティを固めた CSPRNG を使っていないと OAuth ベースサーバを完全に破壊してしまえるものもあります。こうした問題は他のシステムでも非常に困ったものではありますが、動作のすべてが乱数のやりとりの上に成り立っている普通OAuth 実装では、より一層この問題が際立ちます。こうしたトークンは EVS のサーバ側で生成され、「普通実装における」OAuth がよくやる使い方ではサーバ信頼性を奪い、関連するトークンすべての予測可能性を高めていきます。最新の攻撃手法を防げるセキュリティ強化 CSPRNG が用意できないのであれば、もっとハードルの低い別のプロトコルに乗り換えたほうが良いでしょう。

一方、一部の OAuth ベース実装乱数必要性クライアント側に移すような構造になっていることも注目しましょう。色んな意味で、これは問題を別の場所に移しただけではありますが、サーバ側のアタックサーフィスを減らすのは事実です。これによって、少なくとも情報強者利用者は、信頼できるサービスをセキュアに使うことが可能になります。ただし情報弱者脆弱なまま放置ですが。今回の例に当てはめてみると、この種のセットアップでは AFCP の開発者が頑張って EVS をセキュアに使えるようにすることと、EVS 自体が陥落する危険回避することは可能ですが、ABC や XYZ が EVS をセキュアに利用するかどうかは別問題です。

クロスサイトリクエストフォージェリ (CSRF)

本論に入る前に指摘しておきたいのですが、CSRF 攻撃はその名前に反して、外部サイトからスタートする必要はありません。CSRF 攻撃というのは、自サイトへのリンクユーザが貼れる、掲示板メッセージングソフトのようなサイト自体からでもスタート可能なのです。

色々な手法CSRF に立ち向かうべく設計された数々のテクニックフレームワークがあります。これらのシステムの多くは、OAuth ベースのもの統合すると使いものにならなくなったり、サイト攻撃さらしかねない行為を促すことがあります

CSRF を防止するひとつの仕組みとして、ブラウザから送られる referer (原文ママ) が外部サイトを指していないことを確認するというものがあります。多くの OAuth 実装ユーザ特定の外部サイトから連れてくるよう要求しまから、この防御策は執行できません。OAuth サーバリダイレクトする膨大なサードパーティドメイン、また関係する URL やドメインの完全なリストは明文化されていないうえに折々で変更があるため、EVS のドメインとページ全体をホワイトリストにするのは不可能です。

また、EVS の提供者が寝返って AFCP を攻撃しようとする可能性がないかどうかも検討する必要がありますOAuth の背後にある原則ひとつOAuth ベースサービス側が利用者を信用しないことです、しかし同時に、利用者側には CSRF 回避策を見なかったことにしてサービス側を完全に信用することを要求しています理想認証システムというものがあるとすれば、一方通行ではなく相互レベルの不信を確立するでしょうに。

転送元と転送先のどちらかだけの、部分的ホワイトリストというのも難しいことがあります。使っている CSRF 対策フレームワークによりますが、機能オンオフ中間がなく、特定のページや転送元だけを無効にすることができないかもしれないので、その場合 EVS 利用者CSRF 対策フレームワークを一切使用できなくなります

OAuthCSRF 攻撃を防ぐ CSRF トークン指定するようにと、オプショナルな state パラメータ定義していますしかしながら、OAuth ベースサービス一般的state の長さや文字種を制限し、要求どおりそのままでさないことがあるようです。そこで、おかし互換性問題が起こるため、多くの OAuth ベースサービス利用者リダイレクトのエンドポイントにおける CSRF 防御をすべてオフにせざるをえない状況に追いこまれています。これは「10.14. コード・インジェクションと入力バリデーション」に分類されていますstate パラメータの別の懸念は、EVS 側で stateアクセスのある人はだれでも、リクエスト改竄して、それ以外はまったく有効なままのパラメータを付けて AFCP にブラウザを送り返すことができるという点です。

OAuth ベース API の利用者は、自分アプリサービス登録する際にひとつか複数の URI をカッチリ決めておくよう求められるという制限も課せられています。これは redirect_uri に使えるホワイトリスト URI です。この仕組みにひそむ重大なユーザビリティ問題は後述するのでひとまず措くとして、この制限のせいで開発者は、state パラメータや他の潜在的危険の伴うアイディア姑息な工夫をこらし、泥沼に沈んでいくはめになっています。多くの OAuth ベースサーバは、ホワイトリスト URI をひとつしか許可していなかったり redirect_uri との完全一致のみ有効パラメータの追加を認めなかったりしています。このせいで開発者たちは CSRF 対策フレームワークの利用をやめたり、あらゆる危険ものstate パラメータに詰めこもうとし始めたり、浅薄システムを自前で作り出したりしています。その結果、redirect_uri と state の組み合わせによってはユーザ不適切なページに誘導する危険性が出てきます。これは「10.15. オープンリダイレクト」に分類されます

こうしたリダイレクトの問題は、パラメータをしっかり認証していないせいで、それ自体悪用可能なのですが、これを前述の「OAuth サービスへの偽装」問題と組み合わせるとユーザ大惨事をもたらしかねません。盗んだ client_id と client_secret を使えば、悪いやつらは AFCP とまったく同じ情報認証できるので、本物の AFCP にも見ぬけないようなリダイレクトを作ることができます。また、悪意あるユーザも、本来自分の持っていない AFCP 内の権限を取得するような state パラメータの利用方法改竄方法を見つけることができるかもしれません。その際には、おそらく盗んだ認証情報も使うことでしょう。概して、「普通実装における」OAuth の低品質設計のせいで、また特定の分野に関する教育レベルが低い外部開発者の直面する問題のせいで、OAuth ベース利用者に対する攻撃はしばしば、本来あるべき状態よりもずっと容易になっています

ここで読む意義のあるものとして、さらに「3.5. リダイレクト URI」「3.6. state パラメータ」「4.4.1.8. redirect-uri に対する CSRF 攻撃の脅威」があります

章のまとめ

セキュリティに関して言えば、「普通実装における」OAuth仕事ぶりはとてもひどいです。OAuth が目指していると思われるセキュリティ目標の多くは、達成されていません。さらに、OAuth ベースサービスの中には、種々の攻撃に対して無防備でいることを利用者公然要求するものがありますサービスをセキュアに使える場合も、そのことが知られているとは限らず (サービス側の、トークン生成手法といった重要セキュリティ詳細が明文化されていないうえにクローズドソースなため)、OAuth は今なお多くの低品質プログラミング習慣を招いていますOAuth は外部の開発者を守る点でほとんど何もしませんが、そうした開発者が使っている各種フレームワークの方はといえば、こちらも真のセキュリティ提供していなかったり、厳しい自制と注意がなければセキュアに使えなかったりする代物です。

この記事についていえば、個人的蔓延していると思った問題の一部を取り上げたものに過ぎません。この中には、極度に低質な、一切 OAuth の規格で義務付けられていない慣習を、他所OAuth に使っているのを見たまま開発者コピーした結果というものもあります

OAuth ベースサービス開発者もその利用者側の開発者も、OAuth ベースプラットフォーム実装したり利用したりするためには、ここでリンクした文書をすべて読んで理解する必要があります。挙げられている 50 クラス攻撃も、各クラスの深刻度も完全に把握する必要がありますし、そのうえで「実装仕様書セキュリティガイドラインには漏れがないとは限らない」ことにも留意すべきです。この記事は公式文書にない問題をいくつか取り上げているとはいえ、OAuth セキュリティ問題の表面をなでているに過ぎないことも覚えておくべきです。ここに混ざって、公式 OAuth 提案に加えられる変更点はどれもまったく新たなセキュリティ問題を引き起こすものですが、残念ながら変更はよくあることなのです。そこで各々が、乱数生成やセキュリティ調査技術といった OAuth 以外のセキュリティ関連分野も理解していなければ、OAuth でそれなりのレベルセキュリティを実現することはできません。

真のセキュリティをお探しの方には、よそを探すようお勧めします。最後の章で OAuth の代わりになる選択肢をいくつか取り上げます

ユーザビリティ関連

(略: ふつう実装では、サービス側がプラグを引き抜くようにして自由利用者出禁にできる。ビジネス的にもまずいし、悪意あるユーザが API 利用者を騙って出禁になるとアプリへの DoS になる。)

(略: サービスからは API 利用者という大きすぎる単位しか見えないので、たとえばビデオカメラアプリ単位で利用帯域などを制限せざるを得ないが、そうするとそのビデオカメラは、一部ヘビーユーザのせいで他のユーザが締め出される事態になる。OAuth 以外のサービスならふつうユーザ単位対策としてユーザ開発者アカウントを取得してもらうのも面倒すぎる。ていうか手動プロセスを挟んでたり。)

(略: ふつう実装SaaS モデルしか見ていないので、URI を持たない AFCP のような社内ソフトや、ビデオカメラのようなデスクトップアプリには使えない。アプリcURL 的なもので API を叩こうとしても、JavaScript必要だと言い張るサービスもある。グローバル企業が地域別にドメインを分けていたら URI が足りない。客ひとりひとりにサブドメインを与える製品だと URI が足りない。足りるとしても追加・更新メタ API で簡単にできない。ひとつの URI ですべてのリクエストをこなすのセキュリティ問題もあり、ロードバランス等の必要性も出るし、社内ソフトデスクトップアプリに余計なウェブサイトへの依存性を加えることになる。httpサーバlocalhostで立てるとかアホか。)

(略: オープンソースしづらい)

(略: トークンが定期的に期限切れになるので可用性が下がる。たとえばビデオカメラから複数の動画をアップロードしている途中で切れたらムキーってなる。再認証して途中からできるのもそれはそれで CSRF の温床。AFCP のような場合は期限切れがあってはならないので、パスワード等を預かる

OAuthのことを1ミリも知らない俺が

OAuth ディスの記事を酒の勢いで訳してみたゾ。前半はつまらないから、「章のまとめ」か、それ以降だけ読むといいゾ。なぜか後半が切れてた。こっちだけでいいゾ anond:20160426145507 anond:20160426150324

http://insanecoding.blogspot.com/2016/04/oauth-why-it-doesnt-work-and-how-to-zero-day-attack.html

OAuth がうまくいかない理由と、既存サービスゼロデイ攻撃方法

OAuth とは

認証 (authentication: 本人確認) と承認 (authorization: 権限付与) のシステムを設計し、API を規定し、複数の異なるシステムを統合するために用いられる提案をまとめたものです。

OAuth には色々な種類があり、version 1.1a や 2、その各部の上に他の規格を乗せたものなどが存在します。世の中に出回っている数々の実装によって、具体的な利用状況は大きく異なります。

おことわり

前にも OAuth について書いたことがあり、たくさんの反響をいただきました。前回の記事に対する批判の一部を避けるため、今回の記事について先に断っておきたいのですが、この記事は OAuth の使われる典型的な場面に焦点を当てており、論じられる点のほとんどは、何らかの方法OAuth を利用する大手サービスのほとんどすべてに当てはまるということです。

言いかえると、OAuth を用いているあらゆるプラットフォームが壊れているとは限りません。OAuth にはバリエーションが多いうえに、2.0 だけに限っても 76 ページに渡るパターンがありますので、OAuth に基づいた何かに適合していながらもセキュアであり、使っても問題ないものは存在しうると言えます。ですから、あなたお気に入りOAuth 実装や設計が、ここで論じられる問題の一部または全部を免れていることもありえます。確率は低いですが。

また、OAuth を使っているものの中には規格を誤用しているものがあるとか、OAuth はその使い方を強制しているわけではないとか言う人もいるかもしれません。どちらにせよ、ここでは特定の OAuth ベースの規格について述べるのではなく、現状で大手が OAuth をどう利用しているかについてを、それが規格に適っているかどうかに関わりなく論じるつもりです。こうすることで、多くの読者に影響を与えることになるでしょう。危険な方法OAuth を使っているサービス利用者であっても、また自ら OAuth ベースサービスを管理していて、他のみんなが作っているのを真似てプラットフォームを作ろうと思っている人だとしても関係があるのです。

記事の構成

この記事は長くなりますし、言ってみればほとんどの章はそれ自体でひとつの記事として十分なほどの話題を扱いますので、大まかな流れをご説明しておきましょう。

この記事は、現在 OAuth 業界でおこなわれていることを調査した結果のまとめです。OAuth を使う製品のすべてにこの記事のあらゆる点が当てはまるというのではなく、危険だったり無価値だったりするサービスの背後に見つかった慣例や根本原因を紹介する記事です。

この前書きのあとは、まず OAuthセキュリティ欠陥を分析することから始めるつもりです。こうした欠陥の中には、セキュリティコミュニティでよく知られていて、書籍などですでに分析されている一般原則が当てはまるものもあります。しかしこの記事では書籍化されていないケースも扱いますし、有名な欠陥についても、平均的な開発者および責任者に理解しやすく、対策の必要性がはっきりするように工夫するつもりです。

その後は、OAuth の主要素が一般的に言ってどのように実装されており、そうした普通の実装がどのようにサービスを使いものにならなくするのか、すなわちそのサービスで達成できることを極度に、不適切に、かつ意図に反して低下させてしまうのかを分析します。ごく一部のケースでは回避策の足がかりになるかもしれないテクニックについて論じますが、そういうのを実装する馬鹿らしさにも注目します。こうした記述の中では繰り返し何度も、OAuth を使う人たちがどれほど自分と自分のビジネスにとって損なことをしているのかが説明されます。

最後に、OAuth が適切に使われうる数少ない場面と、すでに利用されている OAuth の代替品を簡単に取り上げます。代替技術に関する調査の結果を提供するつもりですが、その中には Amazon のような大企業がセキュアで使いやすく信頼性の高い API を実現するために何をしているかの報告も含まれるでしょう。

責任ある情報公開

いま普通に使われているかたちにおける OAuth の欠陥の幾つかを悪用すれば、大手サービスに対して強力な攻撃を仕掛けることができます。OAuth に対する攻撃は何も新しいものではありません。IBM や Oracle を含め、懸念した IETF メンバーOAuth ベースサービスに対する攻撃を 50 クラスも記述した 71 ページもの文書を 3 年以上前に出したように、また筆者も前回の記事でこうした点のいくつかを議論したようにです。それにも関わらず、OAuth ベースシステムの主要なセキュリティ欠陥は非常に蔓延しています。

筆者は、いくつかの大手企業の役員や開発者に、そこの OAuth ベースシステムが抱えるセキュリティ欠陥を指摘したことがあります (そのうちのひとつは 4 年前のことです) が、全員、自社システムを修正するために一切何もしませんでした。まるで、OAuth の人気度からして、他の現実的な解決策をひとつも聞いたことがなく、それゆえに OAuth が最もセキュアな選択肢に違いないと決めてかかっているようです。どうも、OAuth のコア原則に対する攻撃のデモを文書化した情報も、聞いたことがないか、肩をすくめて無視するかしているようです。そこで、この情報をもっと広く拡散することによって、影響のある人たちの尻を蹴りとばしてあげたい、そしてサービスを設計あるいは管理している人たちにモーニングコールの役割を果たしてあげたいと願っています。

というわけで、OAuth ベースの何かを提供あるいは利用するご自分のサービスを調べて、こうした欠陥の一部あるいは全部が存在することに気づいたなら、どうぞ責任をもってこの情報を取り扱ってください。ご自分のサービスを適切にアップデートしたり、関係する問題に対応するようビジネスパートナーに適切な圧力をかけたりしてください。

ここで言及されている情報やリンクされている情報は今のところ既存のサービス悪用できるかもしれませんが、どうぞ責任ある行動をとり、他人のもの破壊するのではなく改善することを目指してください。この記事は、自社サービス不適切に実装している人たちへのモーニングコールのつもりで、その改善を促すために書いているのであり、悪用したがっているハッカーたちのハウツーもののつもりではないのです。

想定する利用形態

この記事では、ふたつのシナリオに注目して、その場面でどのように OAuth が組み合わされているのか、そしてなぜうまくいかないのかを検討します。記事を通して何度もこれらのシナリオに戻ってきますので、頭に入れておくことは大事です。

まず、Exciting Video Service (略して EVS) というサービスを思い描いてみましょう。ユーザが動画をアップロードしたり友人と共有したりできて、完全公開にしたりアクセス制限を設定したりできるようになっています。また EVS は動画のアップロードや削除、およびだれが視聴できるかの権限管理に OAuth ベースの API を提供しています。

ただ、例としてこの想像上のサービスに焦点をあてますが、論じられる問題はあらゆるサービスにも当てはまります。ファイルであろうと文書ストレージであろうと、カレンダー管理やオンライン会議、ディスカッショングループ、はたまたリソース管理であろうと OAuth ベース API を提供する他のいかなるものであろうとです。また、筆者は本当にどの特定の動画サービスのことも言っていないということを覚えておいてください。問題点の一部あるいは全部は、OAuth を使っている既存の動画サービスに当てはまるかもしれませんが、EVS がそのサービスのことを指すわけではありません。どれが当てはまるかは読者への練習問題ということにしてもいいですね。

ひとつめのシナリオとして、ビデオカメラの製造会社を想定しましょう。そのビデオカメラには、録画した内容を EVS にアップロードする機能のあるソフトウェアを付属させたいと思っています。つまり、ユーザビデオカメラを自分のコンピュータに接続して、その独自ソフトウェアを開き、ビデオカメラからアップロードしたい動画を選んでしばらくすると、それが EVS にアップロードされているというものです。

ふたつめのシナリオとしては、ある中小企業が職員用に EVS で 50 アカウントを購入し、全職員が動画をアップロードして同じ部門の職員と共有できるようにする、ということにしましょう。この会社は A Friendly Custom Platform (AFCP) というソフトウェアで職員と所属部門の管理をしており、この AFCP サービスを EVS に統合したいと考えています。望んでいるのは、管理者が AFCP を使ってだれかを営業部門に配置したら、その職員が自動的営業部門メンバー所有の動画すべてに対するアクセス権を取得するということです。営業部門からいなくなった人には逆のことが起こるようにもしてほしいと思うはずです。

問題点

セキュリティ関連
認証情報の盗難 / アクセス権の詐称

トークンベースの認証システム (OAuth のコア) が現在よく利用されている最大の理由のひとつには、「適切に実装されれば」サードパーティアプリサービスに各ユーザの認証情報 (パスワード等) を提供しなくて済むという点があります。サードパーティに個人ユーザの認証情報を渡すのは、以下の理由から望ましくありません:

上記の問題点は、OAuth だけでなくあらゆるトークンベースの認証システムでも回避できます。よく OAuth の強みとして挙げられていますが、独自というわけでは全然なくて、他にも同じ強みを実現しつつ OAuth の弱点のない選択肢はあるのです。

さて、確固とした土台に基づいてはいるものの、「普通の実装における」OAuth は、上記の問題を回避しようとして以下のような手順に沿ってシステムに情報を提供します:

  1. ユーザサードパーティアプリ/サービス (たとえば AFCP) を訪ねて、特定のサービスと統合したいことを知らせる。
  2. AFCP は、EVS でホスティングされた特別なログインページを出してユーザに EVS の認証情報を入力させる。
  3. EVS は、その指定したアクセスレベルユーザが本当にサードパーティ (AFCP) へ与えたいのか確認する。
  4. EVS は AFCP に一種のトークン (複数の場合もある) を提供し、各種 API コールに使えるようにする。

このトークンユーザの認証情報ではありませんから、そしてひとりのユーザひとつアプリの組み合わせだけに有効で、指定された権限しか持たず、あとから破棄されるようになっていますから、きちんと前述の問題点を回避しているように思えます。しかし実際には、ちゃんとした土台を核として持っているにも関わらず、OAuth の普通の実装で使われているこのフローは、上に挙げた問題すべてに対処しているとは言えません。

この設計はそもそも危険なスタート地点から始まっています。セキュアなプラットフォーム設計の第一原則は、危険な地点から始まったものは既にダメ、逆転不可能、ということです。手順 1 のせいで、EVS 自体ではなく EVS を利用するサービスから始まっているので、ユーザは最初の一歩からして中間者攻撃を受けたような状態にあります。これは、かかってきた電話に個人情報や口座番号などを教えるようなもので、自分の使っているサービスの者だと名乗っていますが、番号が本物かどうか分からなかったり非通知だったり、という場面のコンピュータ版だと言えます。最近はこういう詐欺がたくさんありますから具体例を挙げる必要はありませんね。要点は、接続を開始する相手が信用できなければ、その接続は一切信用できないということです。EVS 自体の側から手順を始めるのでない限り、上に挙げた目標をすべて実現する API 利用のためのセキュアな認証システムは設計不可能です。

(略: 手順 2 で、それっぽいページに誘導すれば認証情報を盗める)

(略: そうした詐欺を企業自体が後押ししているような風潮もある)

(略: スタンドアロンアプリなら、ログインを詐称する必要すらない)

この種の攻撃は前述のセキュリティ文書で「4.1.4. 脆弱性を突かれたブラウザ組み込みブラウザを使ったエンドユーザ認証情報のフィッシング脅威」として分類されています。提案されている解決策は?

クライアントアプリユーザに直接認証情報を求めることは避けるべきだ。加えて、エンドユーザフィッシングや良い習慣について教育を受けることもできる。良い習慣は、たとえば信用できるクライアントにしかアクセスしないことだ。OAuth は悪意あるアプリに対していかなる防御策も提供していないので、エンドユーザインストールするネイティブアプリすべての信頼性に自分で責任を負う。

さらに

クライアント開発者は、ユーザから直接に認証情報を集めるようなクライアントアプリを書くべきではなく、システムブラウザのような信用できるシステムコンポーネントにこの役目を移譲すべきだ。

基本的に言って、OAuthセキュリティガイドラインは、OAuth を利用する開発者ユーザを攻撃しようとすべきではないとか、悪いことをしてはならないと言っています。外部の開発者が悪いことをしないことに頼るというのは、正気のサービス設計者が依拠するセキュリティモデルではありません。

私の知る主要な OAuth ベースサービスはほぼすべて、ここに概説した手法で攻撃可能です。

OAuth こそセキュリティの新たな金字塔だとお考えの皆さん、目を覚ましてください! 「普通の実装における」OAuth は、始まる前から負けていますよ。OAuth が存在するよりずっと前に実装された数多くのシステムはセキュアで、この問題を効率的に回避しています。残念なことに、あまりに多くのサービスが、せっかくセキュアだったのにインセキュアな OAuth モデルに移行してきました。だれかが開発者管理者に「OAuthもっとセキュア」「先取り思考」「将来への投資」とか何とか素敵な (しかし具体性の皆無な) バズワードを並べたてたからでしょう。ほとんどの場合、こうした変更は本当に既存の問題に対応しているのか、あるいは以前のシステムより幾らかでも良くしてくれるのかどうかをレビューすることさえなく実装されています。

OAuth サービスに偽装

OAuth ベースサービス設計でよく見かける間違いは、ブラウザ用に、パラメータひとつとして client_secret (あるいは同様のもの) を受け取るエンドポイントを提供することです。OAuth の client_id と client_secret パラメータは、基本的に言ってサードパーティプラットフォーム固有の API ユーザ名とパスワードと等価ですから、EVS の API を利用する開発者だけにしか知られるべきではありません。パスワード同然のものなのですから、client_secret パラメータは「絶対に」ユーザブラウザを通して送信すべきではありません (ヒント: パラメータ名の中に secret という言葉が入っているよ)。アプリサービスユーザがその client_id と client_secret を見つけることができる場合、そのユーザはそのサービスのふりをすることができ、潜在的には何かイケナイことができてしまうということになります。さらに注意すべき点として、client_secret パラメータを別の名前にするサービスもありますから、ご自分の関係するサービスをよくチェックして、他のパラメータも秘密にする必要があるのかどうかを調べてください。残念ながら、重要な変数が自分の素性をいつも表に出しているとは限らないため、この問題は意外と多く存在しています。加えて、client_id だけ使う認証フローOAuth の上に乗せるサービスも出てくるでしょう。これには用心してください。特定の状況では、そういう client_id はまさしく client_secret 同然の働きをするのですから。

「普通の実装における」OAuth は、ウェブブラウザを使ってユーザを複数のウェブサイトに移動させるわけで、ひとつサイトから別のサイトに client_id と client_secret (あるいは同様のもの) を送ってもらう必要があります。そうやって、たとえば AFCP と EVS の間でこれらをやりとりするわけですから、ユーザブラウザの HTTP ログをモニタリングすれば、本当に見えてしまいます。これはアプリに組み込まれた独自ブラウザ各種でも、単に右クリックすれば何らかのネットワーク・ログ機能を持つ何らかの inspector にアクセスできてしまう場合などには可能です。

EVS と連携した AFCP にこの欠陥があると、AFCP に少しでもアクセス権限のある職員に本来の権限より多い権限を取得させてしまい、本来アクセスできないはずのところに許可が下りてしまう危険があります。別の例では、仮に FacebookGMail 用の OAuth エンドポイントを利用しているとして、client_id と client_secret の両方がブラウザを通して送信される場合、Facebookユーザは全員 GMail に対して Facebookのもののふりをすることができてしまうということです。

この問題は、OAuth エンドポイントユーザウェブブラウザから平文で client_secret を送ってくることを期待するときにはいつも存在します。あるいはそうする必要があると誤解した API 利用者が、埋め込むべきでないところに secret を埋め込むときもです。この脆弱性が存在している可能性が高いのは、エンドポイントが client_secret (または同等品) と redirect_uri の両方を期待する (あるいはオプションとしてでも受け付ける) 場合です。redirect_uri パラメータは、今回のケースで言うと EVS がユーザログインさせたあとでそのブラウザをどこに送るべきか指示するために使うよう設計されています。そうやって redirect_uri がエンドポイントへの転送に使われている場合、その処理はユーザブラウザで実行されることが期待されているわけです。主要な OAuth 文書はどちらも、client_secret と redirect_uri の両方をこうした用途に使うようなケースを指示したり求めたりはしていません。

ざっと検索してみたところ、残念なことに、潜在的に違反の可能性があるそういった OAuth ベース API がたくさん見つかります。GoogleOAuth の色々な利用方法を提案していますが、その中に、両方を一緒に使うことを広めるフローひとつあります:

client_secret: 開発者コンソールで取得したクライアントパスワード (Android, iOS, Chrome アプリとして登録した場合のオプション)

Citrix もこんな間違いをしています:

(略: 以下、実際に脆弱だと確認したわけではないが、secret と redirect を併記しているサイトが列挙されている。)

Google で 2 分検索しただけでこのリストができました。皆様がもうちょっと労力をかければ、ずっと多く見つかることでしょう。ただし、上記リストは、こうしたサービスのどれかが脆弱だとか、誤用しやすすぎるということを直接に示すものではありません。色々な要素があり、たとえば Zendesk は特にこのケースでは redirect_uri パラメータリダイレクトに使わないと明言していますし、アプリからエンドポイントを呼ぶときはフル機能版ブラウザではなく curl を使うべきだとさえ書いて、開発者が危険なことをするような誤解を極力避けようとしています。それでも、経験の浅い開発者はこうしたエンドポイントを独自ブラウザで読もうとするかもしれません。さらに、この組み合わせが世に出回っているというだけで開発者の警戒心が下がっていき、経験を積んだ OAuth ベースサービス開発者でさえも似たような状況で潜在的ヤバイ誤用を気にせず適用するようになってきています。特に client_secret が別の名前になって、「秘密を守る」という概念が失われている場合はそうです。

サービスがこの点に関して壊れている指標となるのは、人気のある複数の OAuth ライブラリがこのサービスでうまく動かないときです。そういうサービス一般的にいって独自の「SDK」を提供しており、サードパーティ開発者が選んだライブラリではこのフランケンシュタイン的な OAuth が使えないと苦情が来たときにはその SDK を使うよう指示します。こうしたカスタマイズは気付かれないまま進行することも多くあります。開発者の大多数は、SDK が提供されているなら、わざわざ手元のソフトで頑張らずに済ませたいと思うものですから。

この種の攻撃は前述のセキュリティ文書で「4.1.1. クライアント機密情報を取得する脅威」に分類されています。しかしサーバウェブブラウザを使用を要求し client_id と client_secret (または似た用途のもの) を同時に渡させるという具体的な攻撃パターンには一言も言及がありません。おそらく、その文書の執筆陣の予想では、こんな馬鹿げたサービスはだれも設計しないだろうし、その API を使う開発者もそれを独自のウェブブラウザや SDK で使ったりはしないだろうと思っていたのでしょう。こうした開発者OAuth の規格からバラバラに取り出した要素をグチャグチャに混ぜて接着しておいて、自分のプラットフォームOAuth 本来のセキュリティを保持していると思っています。そのツギハギのせいでどんな新しい問題が入り込むかもしれないのに、そこは一顧だにしません。残念ながら、これが近年の OAuth 業界によくあるやり方で、この既に猛威をふるっている問題は、パレード参加者がどんどん増えて、人が使っている手法や、使っている「と思う」手法をコピーしていくことで、とどまるところを知らない連鎖になっています。

おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います。特にデスクトップアプリでは、コンパイルされたアプリバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくあります。GoogleOAuth の使い方を多数提供しているうちで、client_secret と redirect_uri を両方受け取るエンドポイントのことが書いてあるのはたったひとつだけだというのは重要な点です。少なくとも Google の場合、redirect_uri があっても、このエンドポイントウェブブラウザベースアプリには推奨していません。しかし、だからといって実際に独自ブラウザでそれを使う人や、このフロー標準的ブラウザ用のエンドポイントコピーする人が一切いなくなるはずがありません。それに加え、Google は例外なのであって、世の中にはセキュアな OAuth フローを受け入れず client_secret (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。

前掲のセキュリティ文書は、 このエントリーをはてなブックマークに追加ツイートシェア

2015-03-26

デフォルトのAnsibleで牛が出る

TL;DR

Ansibleはcowsayがインストールされている場合、cowsayを介してログを出力する仕様になっている。

しかし、cowsayがデフォルトで入っているLinux Mintでは否が応でも大量の牛を見ることに…。

見つけた経緯

最近構成管理ツールを使った環境構築を始めた。

最初Fedora用にとItamaeを使っていたのだが、

Linux Mintでpackageリソースが動かないからとAnsibleへ移行した。

(原因はItamaeではなく内部で使ってるspecinfraにある気がする)

幸い、roleがcookbookと似ており、移行もそれほど苦労せずに済んだ。

Fedora用のplaybookがあらかた完成したので、

今度はLinux Mintのものを、と思ってAnsibleを動かしてみたのだが、

何やら動作がおかしい。

ログアスキーアートと共に出力されるようになった。

PLAY [localhost] ************************************************************** 

GATHERING FACTS *************************************************************** 
ok: [localhost]

 __________________ 
< PLAY [localhost] >
 ------------------ 
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||


 _________________ 
< GATHERING FACTS >
 ----------------- 
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

最初Linux Mint向けのパッケージ特殊仕様になっていると思い、

pipを使って入れなおしてみたが何も変わらず。

再度apt-getで再インストールしても同じだった。

疲れたので原因探求をやめ、

「そういえば、Itamaeの記事で同じアスキーアート見たなー」と思って、

なんとなくでItamaeの記事を読み返してみると、

どうやらcowsayというツールを使うことで牛のアスキーアートを出力できるようだった。

http://qiita.com/tbpgr/items/b47510b01db8697f94c1

とりあえず「Ansible cowsay」でググった。

まさかAnsibleのような真面目なプロダクトでそんなことあるわけ…

と思っていたら本当にcowsayが原因だった。びっくりした><

なにか変な夢でも見てるんだろうと思ったが夢ではなかった。

https://github.com/shkumagai/ansible-doc-ja/blob/master/playbooks2.rst#id26

解決策

Linux Mintではcowsayがデフォルトで入っている。

そのため、牛が出ないようにするには、

export ANSIBLE_NOCOWS=1

bashrcなりzshrcなりに↑のように書くか、

http://docs.ansible.com/faq.html#how-do-i-disable-cowsay

[defaults]
nocows = 1

ansible.cfgに↑のように書くか、

https://support.ansible.com/hc/en-us/articles/201957877-How-do-I-disable-cowsay-

cowsayを削除するかすればいいようだ(やりかたは色々ある)

Ansibleを開発している方々は、

slやcowsayのようなジョークコマンドシステム最初から入ることはない。入れる人は分かっててやっているだろう。」

と踏んでいたのかもしれないが、Linux Mint場合はそうでない…。

2013-09-25

三日間かかってバグ解いたどー

localhost表記のURLに一つだけ127が混じってたために

画面遷移がうまくいかねーという問題に対して。

嬉しい。超すっきりした。

ふらりとやってきて、ここのリファラー頭悪いか

URL表記見たら?とアドバイスくれてそのまま解決に繋がった

大先輩に感謝

新人というのもあるけど、プロジェクト的に時間伸ばしてゆっくりとってくれた

PMにも感謝

Web系の人なら、こんなの一時間もかかんないんだろうなぁと

僻む気持ちもあるが、 いい経験になったと思いつつ。

超しんどかったー。。。あー嬉しー

でも、これ、テスト環境の立ち上げなのよね。

2013-05-13

素人がそこそこのWebサービスをつくる方法

先日「飲み会版ソーシャルランチをつくってみた」を書いた者です。

上の記事では、僕がつくった「飲活」というサービスの説明が大半で、どうやってつくったのかとか説明が少なかったので、今回はそれについて書いてみようかと思います

まずは僕についてさらっと。

失敗

僕は「「飲活」」を作るまでも、iPhoneアプリを開発したり、webサービスメンテナンスをしたりとプログラミングをしておりました。

なので、プログラミング初心者というわけではありません。

しかし僕も何度かwebサービスの立ち上げを挫折しております。4回くらいかな。

最初xoopsを使って、ツイッターで登録企業広告をつぶやいたらポイントをもらえるサービスでした。

なんとxampp門前払いされました。ローカル環境すらつくれませんでした。「くそ初心者時間無駄にするだけだから辞めろ」と言われた気分でした。

xamppだけに2日くらい朝まで格闘してしまい本当に時間無駄しました。当時はapacheの設定とかなんぞや状態ですからね。

次にやろうとしたのが、大学受験生向けのサイトで、受験生に教科ごとの講義をするのではなく、勉強のやり方を教えるよ!ってサイトです。

ほとんどhtmlでできそうなのですが、phpメールを送ることができず挫折しました。

レンタルサーバーを借りたのですが、レンタルサーバーphpの設定をしないといけないのを知らなかったり、やっと解決しても日本語化けに悩まされて止めた覚えがあります。これほど母国語英語だったらどんなに楽かと思った時はありませんよ。プログラミングしてると今でもたまに思います

次が、キックスターターのようでそうでないクラウドファンディングサービスをつくろうとしました。

ここでjavascript出会いました。いや、ちゃんと交際を始めたと言うべきか・・・。それまでjavascriptとすれ違っても虫を決め込んでいたのですが、いざ必要になって呼び止めてみると意外と良い奴でした。

しかし、ajaxにつまづいたり、サイト構成やディレクトリ構成、データベース構成や、デザインの調整などで複雑で面倒になり挫折してしまいました。

こうして書くと、僕がすごい諦めの早いやつで勉強もまともにしないやつみたいに思えますが、半分正解。諦めは悪いけど「ググればいける」という考えで勉強を怠っておりました。

つくりかた

「「飲活」」をつくった実際の流れを書きたいと思います

だいたいプログラミング言語はどれも根本は似ているので、先述の3つ以外のプログラミング言語をやりたいと思ってる人でも参考になると思います

また、以下の内容は、わけわからんけどwebサービスをつくりはじめる方を前提にしています

まずはじめに:開発環境を整える

まずは開発環境を整えましょう。

開発環境とは、自分の書いたプログラムローカル自分パソコン)でのみ動作させる環境です。

まり自分がつくっているものを外部に見られることはありません。

ローカル開発環境必要なモノは以下です。

です。

まずはこれらをインストールしてください。設定などの説明は割愛します。

ステップ1:プログラミングでいったいどんなことができるのかを知る

僕はphpを使いました。

僕もそうでしたが、素人は当然プログラミングの全体像を想像できません。やりたいことを思いついても、どういうコードを書いたらいいかなんてすぐに想像できませんよね。

これも当然ですがその原因は、そもそもプログラムでなにができるか知らないからです。

なので、POSTやSESSION、配列などの基本的なもの存在を知りましょう。そしたら、「このページにはこの機能必要だろう」というのが、"なんとなく"わかります。書き方はこの時点で別に覚えなくて大丈夫です。

例えば、オブジェクトを格納することが出来る「配列」という存在を覚えます

この時点では、配列の作り方のコードとかは覚えなくていいですよ。「配列という存在を知る」ことが重要です。

基本的なことを学ぶときネットではなく本を使う事を薦めます

本は情報が体系的にまとめられていまうので、ネットよりも学びやすいです。

プログラミング10年以上基本部分は変わっていませんので、「古いものを覚えちゃわない?」という無駄心配はなくて大丈夫

一方、発展的なことではネットで学びましょう、というかわからないことがあればネットで探しましょう。

ステップ2:つくりたいwebサービス必要機能を決める

どんなことを実現したいのかというゴールがないと必ず途方にくれます

なので、まずはゴールを設定します。

例えば「「飲活」」なら、

などなど...。

その後に、各ページ毎に必要機能と大まかなそのページのやることを決めます

例えば、ログインページなら・・・

必要機能

ログインページには、ユーザー入力するフォームと送信ボタンがあって、なにも入力されずに送信ボタンが押されたらエラーメッセージを出そう。エラーがなくログイン成功したら、会員専用のエロビデオを見せよう。

とか。

次に、各ページでどんな情報を表示させるかを決めます

例えば、しっかり考えず適当に、登録ユーザープロフィール画面を開発していて、ユーザー名、生年月日、出身大学を表示させるプログラムをつくったとします。

しかし、プロフィール画面が完成した後にメールアドレスも表示させないといけないことに気がついた場合、少しプログラムの変更が必要になります

最初から、どのデータ必要なのかを決めていれば、こうした効率の悪さは回避できます

実際は奇麗に開発できることは少ないですが、何も考えずに開発するよりは効率的です。

大まかな機能ログイン)→具体的な機能ログインページの機能)→具体的にログインページがやること→必要とするデータ

という流れでサイト機能を決めることで、自分のやることが明確になりますし、勉強すべき内容も最小限に抑えられます

ここで、どういうデザインにするのかを決めればもっと後で楽になります

ステップ3: データベースを用意

webサービスには必ず必須となるデータベースについて知る必要があります

僕は、mysqlを使いました。

サーバーさくらインターネットレンタルサーバーを使ったので、さくらインターネットデータベースを利用しました。

ステップ4:必要機能を実現するための方法を見つける

各ページで必要機能とやることを決めたら、それを実現してくれる方法を本やネットで探します。

先述のとおり、必要機能を決めていればそれを実現してくれるもののみを探せばいいので効率的になります

見つけたら、あとはそれを使ってやりたいことをやるだけです。

具体的にはサンプルコードAPIフレームワークライブラリ)を探すべきだと思います

プログラミングに慣れるまではフレームワークを使うと上手く組み込めず、それが挫折の原因にもなりそうなので、主にサンプルコードを探せばいいと思います

なぜなら、楽だからです。その一言に尽きますよ!

プログラミングってなんのためにあるかというと、人々の生活を楽にするためです。

人々を楽にするプログラミングで、わざわざ辛いやり方をするのは最悪です。

なので、どうぞ堂々と怠けてください。他人のつくったコードを使ってください。APIフレームワークを使ってください。

プログラムを書いたらデバッグしたり、ブラウザ(htpp://localhost)で見てやりたいことができているか確認してください。

「「飲活」」の場合は、基本機能


利用したAPIフレームワークは以下。


特にこのサービスには特別なことや難しいことはやっておらず、正直phpの基本がある程度わかっていれば、このサービスの基本的部分は作れてしまます

ステップ5:大まかなプログラムができたら・・・

デザインをつくりましょう。

僕は一から自分デザインを考えたわけではなく、他の素敵なサイトを参考にさせていただきました。

また、サイトの見た目をつくるにはhtmlcss、時にはjavascriptを使う必要があります

オススメなのはtwitter社の提供するTwitter Bootstrapです。

http://twitter.github.io/bootstrap/index.html

これを利用すれば、簡単にかっこいいデザインを作れます

ちなみに、「飲活」は、htmlcssjavascriptjQuery)を使っています

ステップ6:ドメインを取得、サーバーを用意

つくったサイトをみんなに見てもらうためには、外部とネットワークのあるコンピュータアップロードしなければなりませんし、ドメインもなければいけません。

コンピュータにはIPアドレスがあり、ネットワーク上の住所となっています。これにアクセスすると、「飲活」の住所とか「はてな」の住所とかあったりするわけです。これは数字でできており、これを人間が読みやすものにしようというのがドメインです。

hatena.jpとかnomikatsu.comとかですね。これを取得しましょう!

僕はお名前ドットコムで取得しました。

それからサーバーレンタルしましょう。

外部とネットワークのあるコンピュータですね。

自分で作ったり、VPSを使ったりすることもできますが、自分管理をしなくていいという点で楽なので僕はレンタルしています

僕は、さくらインターネットレンタルしています

僕のようにドメイン管理会社サーバー会社が別だといろいろと設定をしなければなりません。

DNSドメインネームサーバ)というのがあり、「このドメインのあるサーバーはこれ、IPアドレスはこれ」と教えてくれるものです。

名前ドットコムで取得したnomikatsu.comは、さくらインターネットサーバにあるよと設定する必要があります

実際には、さくらインターネットネームサーバ情報を知り、お名前ドットコムでnomikatsu.comはこのネームサーバだよと設定してあげるのです。

これで、数分から時間でnomikatsu.comにネットからアクセスすることが出来ました。

ステップ7:サイト公開

あとはサーバーファイルアップロードすれば、インターネット自分のつくったサイトを見れます

ファイルアップロードの仕方ですが、FTPクライアントを使います

僕は、filezillaを使いました。

filezillaからホスト名やユーザー名などを設定してサーバー接続します。

接続できたら、指定のディレクトリファイルアップロードすればOKです!

最後

とにかく作り始めましょう。

僕は、本が書いてあるサンプルコードをそのまま勉強としてやるのはオススメしません。

だって、つまらないですもん。あれは、プログラムを書いていて基本がわからなくなったときに見返せばいいんです。

最初はまず作りたいものを決めて、PHPで何が出来るのかをざっくり勉強して、それを実現するのに必要コードややり方を見つけて、実際に動くものをつくっていってください。

やりたいことをやらなきゃ飽きますし、本のサンプルコードよりも実際にwebサイトをつくった方が覚えます

プログラミングって難しいものではないですよ。

やったことがない人が勝手に難しいと思い込んでいるだけで、意外とやってみれば難しくありません。

簡単とまでは言えませんが、正直誰でもできます

僕の場合は何度かプログラミング挫折しましたが、こうして一つのものをつくることができるようになりましたし、iPhoneアプリなども会社では開発しています

こんなやつでもできるので、諦めなければできます

そんで、とても楽しいです。

本当につくりたいものがあるのなら、一度やってみる価値はありますよ。

追記:

明記してありますが、僕は初心者ではありません。初心者の方が勉強がてらサービスを作る一つのやり方というか流れを紹介したいと思って記事を書きました。

誤解させてしまタイトルすみません

僕自身、なにもわからプログラミングをはじめたときは、どう勉強したらいいかからず辛い思いをしました。

素人がわけわからプログラミングを始めると挫折やすいと思いまして、僕が素人の時を振り返り、そして勉強してきた経験を使って、素人の方にサービスをつくっていく流れを書いたら素人の方も挫折しにくいかと思いました。

なので、僕は初心者ではありませんが経験者として素人サービスをつくっていく方法を書きました。

また、飲活をつくった実際の流れと書きましたが、飲活をつくった流れを利用して、初心者サービスをつくる流れを説明したかったんです。

説明不足でさらに誤解させてしますみません

2013-03-13

サーバ初心者Webサービスを公開するうえで考えたこと

だって自作Webサービス公開しました

http://www.radiosonde.net/

これまで他の人に用意してもらったサーバ自分プログラムを動かしたことはありましたが

自分自身で一からサーバをセットアップしたことはほとんどなかったので、いろいろとハマりました。

作業を進める上で困ったり考えたりしたことを書いていきます

ちなみにサーバ自体はさくらのクラウドOSにはCentOSを使用しているので、それ前提のお話になります

SSHファイヤーウォールの設定

最初サーバを起動してから速やかにSSHファイヤーウォールの設定を変更しました。

はてブなんかでも定期的に話題になっているのでおなじみですね。

SSHポートを22以外の別のポートに変更する

rootによるリモートログインを禁止する

パスワードログインを禁止し、鍵認証有効にする

・念のためrootパスワードを潰しておく

SSHHTTP(S)など、どうしても公開しなければならないポート以外は遮断する

SSHポートについてIP制限が行えるならば尚良い

さらっと書きましたが、設定をミスって自分自身もログインできなくなり、何度かOSの再インストールを繰り返しています

から気付いた事ですが、さくらのクラウドではクラウド管理画面のリモートスクリーン経由でローカルログインできるので

別にOSインストールしなくてもiptablesの設定を変更できたんですよね...

逆に言うといくらファイヤーウォールとSSHを設定しても管理画面にパスワードログイン環境が残ってしまうので

パスワード管理には引き続きしっかり気を使う必要がある。ということでもあります


Webアプリの動作が重い

httpd,php,mySQL,memcachedなど必要サービスインストール、設定し

作成したWebアプリプログラムを乗せて動かしてみました。が、動作が重いような...

開発環境ではさくさく動いていたのに、本番環境ではどのページ遷移ももっさりしています

abで計測してみたところ、開発環境のおよそ2分の1のスコアとなってしまいました。

開発環境が仮想2コアのメモリ1Gだったのに対し、本番環境が仮想1コアのメモリ2G

CPUの性能について半減しているのでそのせいかな、と思いつつ設定を見なおしていたところ

特に使っていないと思われたipv6を停止した途端にパフォーマンス改善されました。

ページ遷移に伴うもっさり感が解消され、abの計測結果も開発環境と遜色ない結果が出ています

デフォルト有効になっていたipv6の影響により余計な処理が走っていたのかもしれません。


サーバから送信したメール迷惑メールと判定される

パフォーマンス改善に喜んだのも束の間、会員登録などの処理でWebアプリからメールを送信したところ、Gmail宛のメールがことごとく迷惑メールと判定されるという事案が発生。

spfの設定を行なうメールの内容について吟味するなどの回避策を試してみましたが一向に改善されません。

試しにHotMailexciteメールアカウントに送信したところ、そちらではそもそもメールを受け付けてもらえずエラーコードが返って来る始末。

困り果てていたところ、エラーの内容からサーバIPがspamhousにスパム送信元として登録されていることが判明しました。

postfixホスト名の設定がデフォルトで「localhost.localdomain」などとなっており、それをそのまま使っていたためにGmailスパム送信元として通報してしまったようです。

設定を修正し、spamhousに解除依頼を提出。事なきを得ました。


KVSの変更

クラウドを利用すれば、サーバを停止することなく簡単な設定でスケールできるようになる。

と、自分勝手に思い込んでいたせいなのですが、消えては困るデータの一部をmemcachedに保存する実装を行なっていました。

実際のところさくらのクラウドではサーバを完全に停止しなければプラン変更を実施できないし

そもそもサーバが落ちたらどうするんだよ。ということで、急遽KVSを変更する必要に迫られました。

速度の低下が気にかかったため、いくつかの候補を実際に動かし

phpスクリプトから1万件のデータ読み書きを行うという形でmemcached比較してみたところ次のような結果に。

サービス1万件書込1万件読込
memcached 2.55秒 2.30秒
handlersocket 21.23 2.71秒
InnoDB20.23 5.10
kyotoTycoon 8.22秒 7.72秒

さすがに読み書きそれぞれmemcachedが最速ですが、読み出しについてはhandlersocketも負けていません。mySQLから普通にSELECTしてもmemcachedの2倍程度の時間しかからないという結果が意外でした。

しかしながら書き込みのほうではhandlersocketもmemcached10倍近くの時間がかかっており、少々速度的な影響が気になってきますmemcachedの倍のパフォーマンスを記録したという記事を見たことがあるので、設定、チューニングについて生かしきれていない部分があるのかもしれないとも思いましたが、知識が不足しているところで無理をすると問題が発生した時に対処できないと考え、候補から除外することとしました。

結局、今回の用途では読み込み処理より書き込み処理のほうが圧倒的に多いことも考慮し、kyotoTycoonを採用しました。実際の利用箇所に組み込んでabで計測してみたところ、だいたい30%程度のパフォーマンス低下にとどまっており、これなら許容範囲かと考えています

mySQLレプリケーションが止まる

実行系と参照系に分ける形でmySQLレプリケーションを行なっていたのですが、度々レプリケーションが停止する現象が発生しました。

一部のテーブルについて肥大する可能性が考えられたため、参照系に接続するプログラムで使わないテーブルをレプリケーションから除外していたのが原因です。

例えばtabelAをレプリケーションし、tableXをレプリケーションしないという設定にしたうえで

実行系でINSERT INTO `tableA` SELECT `value` FROM `tableX`などといったクエリを発行すると、参照系にtableXが無いためエラーが発生して止まってしまます

レプリケーションするテーブルを限定する場合プログラム側でも注意を払わないと危険です。当たり前ですが。

サーバ監視にmonitを使用

監視といえばcactinagios定番なのかもしれませんが、設定が複雑そうで尻込みし、monitを使用することにしました。

簡単な設定でloadaverageやメモリHDDの使用量をチェックできるほか

httpdmysqldなどといったサービスプロセス監視し、もし落ちていたら自動で起動してくれるので助かります

Webアプリの秘匿

パスワード保護を行うとしても、サイト全体の管理画面など自分しか使わないプログラムWeb晒しておきたくない。

というわけで、一部のWebアプリを秘匿する設定を行いました。

管理画面のWebアプリを9999番など閉じているポートに設置した上で、SSHを利用したトンネルを掘ります。といっても

ssh -t -L 9999:localhost:9999 user@xxx.xxx.xxx.xxx

上記のようなコマンド管理画面のWebアプリを置いたサーバログインするだけです。

ブラウザアドレス欄にhttp://localhost:9999/と打ち込めば、接続が開いている間のみアクセス可能になる感じですね。

サーバログインできる人でなければ実行できないことなので、気分的にある程度安心します。

SSHログバックアップ

自動ログバックアップを行いたいと考えたのですが、パスワード無しの鍵でログインして転送する形には抵抗がありました。

調べてみたところ、authorized_keysに公開鍵を記入する際の設定で、その鍵でできることを制限するという手段があるようでした。

具体的には、authorized_keysに

no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="some commands" ssh-rsa AAAAB3NzaC1yc2EAAA...

などとして公開鍵を追加しておくと、その鍵でログインした直後にcommand=""の部分で設定したコマンドを実行して接続を終了する挙動となり

接続フォワードもできなくなるため、パスワード無しでも鍵の流出に関するリスクを最低限に留めることができるというわけです。

commandの実行結果は標準出力から受け取ることができるので、例えばcommand=""の部分にファイルの内容を表示する処理を設定していたとすれば

ssh -i .ssh/no_password_key user@xxx.xxx.xxx.xxx > /path/to/file

などとしてログインの結果をファイルに書き込むだけで、簡単にファイル転送が実現できます


まとめ

他にも大小さまざまな問題に行きあたりましたが、忘れてしまったor書ききれないのでここまでとします。

たった1つのサイトを公開するにしても問題というのは尽きないものだと実感させられました。

今は基本的な情報だけでなく、ちょっと突っ込んだ内容でも検索で解決していけるので嬉しいですね。手がかりを残してくれた先達に感謝することしきりです。

現状ではひとまずの見切りを付けて公開していますが、より堅牢で負荷に強いサーバとなるよう、随時チューニングを行なっていこうと考えています

最後

作ったWebサービスについて少し書きます

サイト名は「Radiosonde」

個人サイトや小規模な商業サイトなどプロモーションにあまりお金をかけられないサイトを主な対象とした、無料で出稿できる広告ネットワークサービスです。

既存サービスで近いのは「あわせて読みたい」や「zenback」、各社提供RSS相互リンクサービスなどになるでしょうか。

広告としての体裁がある分、それらより若干積極的な性質になるのではと考えています

現時点ではサービス本体のプロモーションに苦心するという本末転倒のものの状況でありますが、もしよろしければ見ていただけると嬉しいです。

2012-08-27

サーバ情報監視の仕組み

cf). Software Design 2010/01号

vmstat を実行するスクリプトを書く
!#/bin/sh
vmstat 5 2 | tail -1 | awk '{print $4,$5,$6}'
xinetd のサービスとして動くようにする
  1. /etc/services にポートプロトコルを登録する
    • agent_mem 11001/tcp # memory monitoring
  2. xinetd が実行するための設定ファイルを書く
    • /etc/xinetd.d/agent_mem
  3. xinetd の再起動
  4. telnet で動作確認する
service agent_mem
{
        socket_type     = stream
        protocol        = tcp
        wait            = no
        user            = nobody
        server          = Monitor/agent_mem.sh
        only_from       = 127.0.0.1
        disable         = no
}
xinetd に登録したポートを叩くスクリプトを書く

php場合、fopen() でもいけると思うのだが、明示的に sockopen() を使う。うむ、perlよりも楽だわこりゃ。

<?php /* -*-java-*- */
/**
 * モニタリングクライアント
 * 
 */
$fp = fsockopen( 'localhost', 11001, $errno, $errmsg, 30 );
if ( !$fp ) {
    echo "Error: $errno - $errmsg \n";
}
else {
    echo date('Y-m-d H:i:s'). "\t";
    $stmt = fgets ( $fp, 128 );
    if ( preg_match( "/([0-9]+) ([0-9]+) ([0-9]+)/", $stmt, $regs ) ) {
        $total = (int)$regs[1] + (int)$regs[2] + (int)$regs[3];
        echo $regs[1]."\t".$regs[2]."\t".$regs[3]."\t".$total."\n";
    }
    fclose( $fp );
}
cron に登録してログを取る。もしくは、スクリプトを while(1)で実行させておく

こいつをモニターとして走らせっぱなしに出来るようにする。

<?php /* -*-java-*- */
/**
 * モニタリングクライアント
 * 
 */

function mem_monitor ( $host, $port ) {
    $fp = fsockopen( $host, $port, $errno, $errmsg, 30 );
    if ( !$fp ) {
        echo date('Y-m-d H:i:s'). "\t";        echo "Error: $errno - $errmsg \n";
    }
    else {
        echo date('Y-m-d H:i:s'). "\t";        $stmt = fgets ( $fp, 128 );
        if ( preg_match( "/([0-9]+) ([0-9]+) ([0-9]+)/", $stmt, $regs ) ) {
            $total = (int)$regs[1] + (int)$regs[2] + (int)$regs[3];
            echo $regs[1]."\t".$regs[2]."\t".$regs[3]."\t".$total."\n";
        }
        fclose( $fp );
    }
}

while( 1 ) {
    mem_monitor( 'localhost', 11001 );
    ob_flush();
    flush();
    sleep( 30 );
}

2010-04-22

Redmine 0.9.3をTomcat 6で実行する方法

結構苦労したので健忘録として。。

環境は以下のとおり

JDK, Tomcat, JRubyインストール済み

MySQLインストール
yum install mysql-server
MySQLの起動
/etc/init.d/mysqld start
MySQLの設定

rootパスワードなどを設定する

mysql_secure_installation
Rubyモジュールインストール

RubyGemsモジュールインストールする

jruby -S gem install rails
jruby -S gem install warbler
jruby -S gem install activerecord-jdbc-adapter
jruby -S gem install activerecord-jdbcmysql-adapter
jruby -S gem install jdbc-mysql
MySQLRedmineデータベースを作成
mysql -u root -p
mysql> create database redmine character set utf8;
mysql> grant all privileges on redmine.* to 'redmine'@'localhost' identified by 'redmine';
mysql> exit

(ここでは、パスワードredmineしているが自由に)

RedmineDB設定

(任意の場所にRedmine解凍して、解凍先のディレクトリに移動した後)

cp config/database.yml.example config/database.yml
vi config/database.yml

database.yml

production:
  adapter: jdbcmysql
  database: redmine
  host: localhost
  username: redmine
  password: redmine
  encoding: utf8

#development:
#
#
#test:
#
#

後のwarbleでのエラーを防ぐため、developmentとtestコメントアウト

DBへのデータ投入
jruby -S rake generate_session_store
jruby -S rake db:migrate RAILS_ENV=production
jruby -S rake load_default_data RAILS_ENV=production
起動確認

script/serverで起動し、http://localhost:3000 にアクセスして正常に動作するか確認する

jruby script/server -e production
production.rbの修正

Tomcatで動かしたときにログ出力するための設定をする

vi config/environments/production.rb
config.logger = Logger.new(config.log_path)
config.logger.level = Logger::INFO
warblerの設定

warble.rbを生成

jruby -S warble config

warble.rbを修正

vi config/warble.rb
  config.dirs = %w(app config lib log vendor tmp extra files lang)
  config.gems = ["jdbc-mysql", "activerecord-jdbcmysql-adapter", "activerecord-jdbc-adapter"]
  config.gems["rails"] = "2.3.5"
  config.gems["rack"] = "1.0.1"
  config.webxml.rails.env = "production"

warファイルを作成

jruby -S warble

できたwarファイルTomcatに配置して、Tomcatを起動する

mv redmine-0.9.3.war /usr/local/tomcat/webapps/redmine.war
/usr/local/tomcat/bin/startup.sh

warblerのバグ(?)でwarに入らないファイルコピーして入れる

cp vendor/gems/rubytree-0.5.2/.specification /usr/local/tomcat/webapps/redmine/WEB-INF/vendor/gems/rubytree-0.5.2

http://localhost:8080/redmine/ にアクセスしてインストールできたか確認して完了!

2009-01-31

最新版Ruby-1.9.1を思う存分試してみたい人のためのちょっとしたハック

Ruby-1.9.1リリースおめでとう!

http://www.ruby-lang.org/ja/news/2009/01/30/ruby-1-9-1-released/

まあ、ライブラリがぜんぜん1.9に対応してないから今すぐ1.8から移行するなんてことはできないんだけど、こうやって安定版を出せばライブラリの移行を促せるんだから、ちょうど鶏が先か卵が先かみたいなもんで、リリースすることに意味があるんだよね。

ところで、Ruby といえば、そのままコマンドラインruby を使っている人はあんまりいなくて、普通irb を使うよね。でも、単に ruby自分のホームディレクトリmake しただけだと、当然、irb は使えないんだ。でもこれだけためにインストールするのは嫌。そこでどうするか?

実は最近rubyMakefile には作ったばっかりの rubyライブラリパス込みで動作させるコードが入ってる。これを使って irb を動かしてみるというのが今回のハックのネタというわけ。

masuda@localhost:~/ruby-1.9.1-p0 $ makerubymake はすべて終了したとする)

masuda@localhost:~/ruby-1.9.1-p0 $ cat > test.rb
require 'irb'
require 'irb/completion'
IRB.start
^D
(^D はCtrl-dで入力終了のこと。普通は表示されない)

masuda@localhost:~/ruby-1.9.1-p0 $ make runruby
./miniruby -I./lib -I.ext/common -I./- -r./ext/purelib.rb  ./runruby.rb --extout=.ext  -- ./test.rb
irb(main):001:0> puts "Have a fun!"

これで適切なライブラリパスが指定されて、その場で最新の ruby が使い放題だ。Readlineを使ってるから編集も楽だし、マジおすすめ

というわけで、Ruby開発者さんたちに感謝しつつ、Enjoy Hacking! ピース

2008-12-21

なんかmysqlユーザの権限設定て意味不明じゃないか?

username@localhostとusername@%はまったく別の設定なのか?

そしてcreateをrevokeしても普通にcreateできてしまったり

よくわからない。

というような愚痴や相談をリアルタイムにできるチャットがほしい。

2008-08-10

Windows起動後に自動起動するアプリケーションの順番を指定する方法

単に起動させるだけで良いならば「スタートアップ」に起動させたいプログラムファイルショートカットを片っ端からぶち込めば良いわけだが、Photoshopのような巨大なプログラムメモ帳のような軽いプログラムを同時に起動すれば、十中八九メモ帳が先に起動してしまうわけで。人によってはそういったプログラムの起動する順番まで制御したいという人も居るはず。タスクバーやタスクトレイの並び方に気を遣う人も居るだろうしね。

以下の手法はそういった人向け。

スタートアップフォルダを開き、(任意の名前).batというファイルを作成する。

「新規作成」→「テキスト ドキュメント」。これは誰にでも出来るはず。

作成したファイルに以下のように記述する

START "" "C:\WINDOWS\NOTEPAD.EXE"

STARTコマンドで、任意のプログラムを開かせる事が出来る。

第一パラメータは何も指定せず、ダブルクオーテーション「"」を二つ並べ、第二パラメータに起動させたいプログラムファイルパスを書く。上記例はメモ帳を起動させる場合。

次に起動させたいプログラムを書く前に

このまま二行目を同じように書くと、スタートアップショートカットを並べるやり方と実質的に同じになってしまうので、ここでひと工夫入れる。要するに、前の行で指定したプログラムが起動し終えるまで次の行の実行をある程度待機させれば良いわけで、自分の場合は以下のように書いている。

START "" "C:\WINDOWS\NOTEPAD.EXE"
PING -n 10 localhost
START "" "C:\WINDOWS\SYSTEM32\CALC.EXE"

一行目を実行した後、LOCALHOST、つまり自分自身に10秒ほどPINGを打ち続けるコマンドを挟み、その後二つ目プログラム(上記例では電卓)を起動させている。これで前の行のプログラム起動に十分な時間が確保され、起動する順番が思い通りになる、という寸法。

ウィルス対策ソフト等のサービスが完全に起動し終えるまで実行したくないという場合、PINGコマンドの方を一行目に書いて、打ち続ける秒数を少し長く(60秒程度)指定しておけば、最初に起動するタイミングを遅らせる事も可能。

もう少しマシな方法もあるような気もするんだけどね。知ってる人が居たらフォローお願い。

2008-06-15

safariはてなブックマーク接続しようとするとInternal Server Error

先週ぐらいから、mac safariはてなブックマーク接続できなくなってしまった。

Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator, root@localhost and inform them of the time the error occurred, and anything you might have done that may have caused the error.

More information about this error may be available in the server error log.

Internal Server Errorってことだから、はてブ側のサーバの問題ってことなのかな。こちらの設定は特にいじってないんだけど。

ちなみに、firefoxだとつながる。http://b.hatena.ne.jp/も表示できるし、自アカログインして、ブックマークの追加もできる。

次いでにいうと、友人のmac safariだと普通に表示される。おれのmac safariだけ表示できない。

ほかに同様の現象で困っている人いますか?

2008-04-15

linuxtreeコマンドの出力をかっこよくできないかなの巻

便利すぐる!とか思ったんだけど、オプション次第では出力がちょっと汚い。

これってうまいこと成形できないかな。かな。

とりあえずオプションは-pugsくらいでおk

treeって何よ?

これ。

http://arbolbell.jp/tools/2007/11/linux-tree.html

使ってみた

[root@localhost www]# tree

.
|-- cgi-bin
|-- error
|   |-- HTTP_BAD_GATEWAY.html.var
|   |-- HTTP_BAD_REQUEST.html.var
|   |-- HTTP_FORBIDDEN.html.var
|   |-- HTTP_GONE.html.var
|   |-- HTTP_INTERNAL_SERVER_ERROR.html.var
|   |-- HTTP_LENGTH_REQUIRED.html.var
|   |-- HTTP_METHOD_NOT_ALLOWED.html.var
|   |-- HTTP_NOT_FOUND.html.var
|   |-- HTTP_NOT_IMPLEMENTED.html.var
|   |-- HTTP_PRECONDITION_FAILED.html.var
|   |-- HTTP_REQUEST_ENTITY_TOO_LARGE.html.var
|   |-- HTTP_REQUEST_TIME_OUT.html.var
|   |-- HTTP_REQUEST_URI_TOO_LARGE.html.var
|   |-- HTTP_SERVICE_UNAVAILABLE.html.var
|   |-- HTTP_UNAUTHORIZED.html.var
|   |-- HTTP_UNSUPPORTED_MEDIA_TYPE.html.var
|   |-- HTTP_VARIANT_ALSO_VARIES.html.var
|   |-- README
|   |-- contact.html.var
|   |-- include
|   |   |-- bottom.html
|   |   |-- spacer.html
|   |   `-- top.html
|   `-- noindex.html
|-- html以下略

こんな感じで出してくれる。超便利。

何したいのさ?

オプションつけると付加情報も表示してくれるんだけど、

[root@localhost www]# tree -pugs

.
|-- [drwxr-xr-x hoge     hoge          4096]  cgi-bin
|-- [drwxr-xr-x hoge     hoge          4096]  error
|   |-- [-rw-r--r-- hoge     hoge          9108]  HTTP_BAD_GATEWAY.html.var
|   |-- [-rw-r--r-- hoge     hoge          6633]  HTTP_BAD_REQUEST.html.var
|   |-- [-rw-r--r-- hoge     hoge         11193]  HTTP_FORBIDDEN.html.var
|   |-- [-rw-r--r-- hoge     hoge         12700]  HTTP_GONE.html.var
|   |-- [-rw-r--r-- hoge     hoge         12846]  HTTP_INTERNAL_SERVER_ERROR.html.var
|   |-- [-rw-r--r-- hoge     hoge          7539]  HTTP_LENGTH_REQUIRED.html.var
|   |-- [-rw-r--r-- hoge     hoge          6773]  HTTP_METHOD_NOT_ALLOWED.html.var
|   |-- [-rw-r--r-- hoge     hoge         13255]  HTTP_NOT_FOUND.html.var
|   |-- [-rw-r--r-- hoge     hoge          6336]  HTTP_NOT_IMPLEMENTED.html.var
|   |-- [-rw-r--r-- hoge     hoge          6565]  HTTP_PRECONDITION_FAILED.html.var
|   |-- [-rw-r--r-- hoge     hoge          7802]  HTTP_REQUEST_ENTITY_TOO_LARGE.html.var
|   |-- [-rw-r--r-- hoge     hoge          7099]  HTTP_REQUEST_TIME_OUT.html.var
|   |-- [-rw-r--r-- hoge     hoge          7103]  HTTP_REQUEST_URI_TOO_LARGE.html.var
|   |-- [-rw-r--r-- hoge     hoge          7822]  HTTP_SERVICE_UNAVAILABLE.html.var
|   |-- [-rw-r--r-- hoge     hoge         13035]  HTTP_UNAUTHORIZED.html.var
|   |-- [-rw-r--r-- hoge     hoge          6353]  HTTP_UNSUPPORTED_MEDIA_TYPE.html.var
|   |-- [-rw-r--r-- hoge     hoge          7009]  HTTP_VARIANT_ALSO_VARIES.html.var
|   |-- [-rw-r--r-- hoge     hoge          1979]  README
|   |-- [-rw-r--r-- hoge     hoge          4256]  contact.html.var
|   |-- [drwxr-xr-x hoge     hoge          4096]  include
|   |   |-- [-rw-r--r-- hoge     hoge           291]  bottom.html
|   |   |-- [-rw-r--r-- hoge     hoge             9]  spacer.html
|   |   `-- [-rw-r--r-- hoge     hoge           969]  top.html
|   `-- [-rw-r--r-- hoge     hoge          5043]  noindex.html
|-- [drwxr-xr-x hoge     hoge          4096]  html以下略

いまいちかっちょわるい。

体裁とか好きなようにいじれたらそのまま書類にできるんだけどなーと。

欲しいものをまとめると

http://anond.hatelabo.jp/20080415182703

てな感じです。

とある増田さん@エロゲ^H^H^Hギークの回答

http://anond.hatelabo.jp/20080416071526

雛型をtreetest.plとして保存して動かすとこんな感じになりました。

[root@localhost www]# perl ./treetest.pl

.
|--                                             [drwxr-xr-x hoge     hoge          4096]  cgi-bin
|--                                             [drwxr-xr-x hoge     hoge          4096]  error
|   |--                                         [-rw-r--r-- hoge     hoge          9108]  HTTP_BAD_GATEWAY.html.var
|   |--                                         [-rw-r--r-- hoge     hoge          6633]  HTTP_BAD_REQUEST.html.var
|   |--                                         [-rw-r--r-- hoge     hoge         11193]  HTTP_FORBIDDEN.html.var
|   |--                                         [-rw-r--r-- hoge     hoge         12700]  HTTP_GONE.html.var
|   |--                                         [-rw-r--r-- hoge     hoge         12846]  HTTP_INTERNAL_SERVER_ERROR.html.var
|   |--                                         [-rw-r--r-- hoge     hoge          7539]  HTTP_LENGTH_REQUIRED.html.var
|   |--                                         [-rw-r--r-- hoge     hoge          6773]  HTTP_METHOD_NOT_ALLOWED.html.var
|   |--                                         [-rw-r--r-- hoge     hoge         13255]  HTTP_NOT_FOUND.html.var
|   |--                                         [-rw-r--r-- hoge     hoge          6336]  HTTP_NOT_IMPLEMENTED.html.var
|   |--                                         [-rw-r--r-- hoge     hoge          6565]  HTTP_PRECONDITION_FAILED.html.var
|   |--                                         [-rw-r--r-- hoge     hoge          7802]  HTTP_REQUEST_ENTITY_TOO_LARGE.html.var
|   |--                                         [-rw-r--r-- hoge     hoge          7099]  HTTP_REQUEST_TIME_OUT.html.var
|   |--                                         [-rw-r--r-- hoge     hoge          7103]  HTTP_REQUEST_URI_TOO_LARGE.html.var
|   |--                                         [-rw-r--r-- hoge     hoge          7822]  HTTP_SERVICE_UNAVAILABLE.html.var
|   |--                                         [-rw-r--r-- hoge     hoge         13035]  HTTP_UNAUTHORIZED.html.var
|   |--                                         [-rw-r--r-- hoge     hoge          6353]  HTTP_UNSUPPORTED_MEDIA_TYPE.html.var
|   |--                                         [-rw-r--r-- hoge     hoge          7009]  HTTP_VARIANT_ALSO_VARIES.html.var
|   |--                                         [-rw-r--r-- hoge     hoge          1979]  README
|   |--                                         [-rw-r--r-- hoge     hoge          4256]  contact.html.var
|   |--                                         [drwxr-xr-x hoge     hoge          4096]  include
|   |   |--                                     [-rw-r--r-- hoge     hoge           291]  bottom.html
|   |   |--                                     [-rw-r--r-- hoge     hoge             9]  spacer.html
|   |   `--                                     [-rw-r--r-- hoge     hoge           969]  top.html
|   `--                                         [-rw-r--r-- hoge     hoge          5043]  noindex.html
|--                                             [drwxr-xr-x hoge     hoge          4096]  html以下略

ステキすぐる。

これを元にいろいろいぢくればcodereposでコミっても怒られないものができそう。

Format.pmもかなり使えそうと言うか僕の要求ずばりですよ。

感謝感激猫ひろし

このエントリTBとかブクマ次第でいろいろ更新される予定だよ。

エントリ自体がスルーされたら泣きながらどっか行くつもりだったけどスルーされなかったのでどっかには行かないよ。

2007-10-10

nicocacheの最初のバージョン使ってる人は早くバージョンアップしたほうが良いと思うんです。

2007/10/08 0.04

* ローカルプロキシとしての利用に限定できるようにするためlocalhost接続のみ受け付けるようにする。

 
アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん