懐かしのCGI掲示板スクリプトをAWS Lambda＋EFSで動かしてみた - めもおきば
AWSにはフルマネージドなNFSファイルシステムを提供するEFSがありますが、AWS Lambdaからマウントできるようになりました。 aws.amazon.com これをうまく使うと、ファイルシステムへの保存を前提とした古いアプリケーションを楽にクラウドにリフト（移行）することができます。 というわけで、さっそく、前世紀からインターネットで遊んでいた人でお世話にならなかった人は居ないであろうCGI RESCUE様のminibbs.cgiこと簡易ＢＢＳをサーバーレスに動かしてみました。みんなminibbs.cgiの書き換えでPerl覚えましたよね？ 動いているもの df6mbqlkt7.execute-api.ap-northeast-1.amazonaws.com ※インターネット老人会の治安が悪いので注意 ※ここはそのうち忘れないうちに落とします。 レポジトリ github.com し
2016年のサーバレスアーキテクチャ総まとめ - めもおきば
この記事は、Serverless Advent Calendar 2016の16日分(だったはずのもの)です。 なんとかクリスマスまでには間に合ったのでお許しくださいorz まとめ AWS Lambdaの功罪で混在されがちな概念が整理されて議論されるようになった 提供されるBaaSのみを使ってリッチアプリケーションを開発する手法 フルマネージドなFaaSの実行環境 高水準コンポーネントをイベントで接続するリアクティブシステム 主要各社のFaaS実行環境が揃ってきた AWS Lambda Azure Functions (2016-11-15 GA!) IBM OpenWhisk (2016-12-14 GA! おめでとうございます!) Google Cloud Functions (2016-02-13 Alpha) 国内のニフティクラウドからも サーバレスアーキテクチャにまつわる様々な動
「通信の最適化」の論点 - めもおきば
論点書き出してみたけど多すぎて超絶カオス。 現状発生している実害 チェックサム比較の失敗(発端) 画質の劣化 exif等メタデータ削除による情報欠損 元ファイルよりサイズが増える 技術的詳細が非公開 「最適化」という単語の是非 オプトインとオプトアウト 送信者(コンテンツ提供者)の同意 自衛のために全HTTPS化することで、かえってトラフィック増える問題 HTTPS化による計算機コスト、ファイル改竄による不具合対応のリスクの負担 サービス内容の意図しない/再現が難しい劣化*1 受信者の財産権の侵害とも言える。 受信者(顧客)の同意 消費者保護観点からより深い内容周知の上での同意が必要では無いか オプトアウトが可能かどうか ISPとしてのサービスが土管であるべきか否か 例えば、可逆圧縮での再圧縮なら良かったのかどうか 携帯キャリアが提供しているのは「インターネット」サービスかどうか iモード
Superfish/eDellRootが危険な理由 - めもおきば
Lenovo製のPCの一部にSuperfishというマルウェアが標準でインストールされていることが確認され、大きな問題となっています。 [2015-11-24追記] DELL製のPCにも、「eDellRoot」とされるSuperfishと同様の問題を持つルート証明書が導入されているようです。 DellのPCに不審なルート証明書、LenovoのSuperfishと同じ問題か - ITmedia エンタープライズ Dude, You Got Dell’d: Publishing Your Privates - Blog - Duo Security Joe Nord personal blog: New Dell computer comes with a eDellRoot trusted root certificate https://t.co/chURwV7eNE eDellRootで
OpenSSLの脆弱性で想定されるリスク - めもおきば
JVNやJPCERT/CCの記事があまりにもさらっと書かれていて、具体的なリスクが想像しづらいと思うので説明します。 今北産業 (今ニュース見て来たから三行で教えて欲しいという人向けのまとめ) インターネット上の「暗号化」に使われているOpenSSLというソフトウェアが2年間壊れていました。 このソフトウェアは便利なので、FacebookだとかYouTubeだとか、あちこちのウェブサイトで使っていました。 他の人の入力したIDとかパスワードとかクレカ番号とかを、悪い人が見ることができてしまいます。(実際に漏れてる例) 他にも色々漏れてますが、とりあえずエンジニア以外の人が覚えておくべきはここまででOKです。もう少し分かりやすい情報が以下にあります。 OpenSSL の脆弱性に対する、ウェブサイト利用者（一般ユーザ）の対応について まだ直っていないウェブサイトもあれば、元々壊れていないウェブ
ウェブアプリにおけるBash脆弱性の即死条件 #ShellShock - めもおきば
条件1. /bin/shの実体がbashのディストリビューション RHEL CentOS Scientific Linux Fedora Amazon Linux openSUSE Arch Linux (自ら設定した場合: Debian, Ubuntu) 条件2. 動作環境 CGI (レンタルサーバでありがちなCGIモードのPHP等も含む) Passenger(Ruby) 条件3. プログラム内容 Passengerは全死亡 *1 systemや `command`、 '| /usr/lib/sendmail' などで外部コマンド実行 *2 PHPのmailやmb_send_mail、その他フレームワーク等を介したメール送信 *3 以下は条件1が不要 明示的にbashを呼ぶ 先頭で #!/bin/bash や #!/usr/bin/env bash しているプログラムを実行 (rbenv
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
