SRE NEXT 2022 ONLINEの発表資料まとめ - QiitaRegister as a new user and use Qiita more conveniently You get articles that match your needsYou can efficiently read back useful informationYou can use dark themeWhat you can do with signing up
SSH の id_rsa.pub を RFC4716 形式で出力する
Microsoft の Azule で仮想PCを作成しようとしたら SSH の公開鍵を要求されて、id_rsa.pub の内容をコピペしたら ''---- BEGIN SSH2 PUBLIC KEY ----'' で始まる形式にしろと言われたので変換。 $ ssh-keygen -e -f ~/.ssh/id_rsa.pub ---- BEGIN SSH2 PUBLIC KEY ---- Comment: "2048-bit RSA, converted by suisui from Ope" <BASE64 ENCODED KEY ...> ---- END SSH2 PUBLIC KEY ---- 逆向きの変換は、先に検索でヒットしたのだけど、自分の欲しい出力が RFC4716 形式だったので。何のことはない ssh-keygen --help を読めば書いてあった 逆 (IN: RF
証明書300万件を強制失効。Let's Encrypt に一体何が起きたのか？ - Qiita
無料 SSL の認証局である Let's Encrypt は、有効な証明書のうち 2.6% に当たる300万件の証明書に対し、2020年3月4日に失効手続きを行うと宣言しました。しかもその事がユーザーに通知されたのは失効手続きの数時間前です。一体、Let's Encrypt に何が起きたのでしょうか？ 私が調べた事を共有したいと思います。 この記事は Let's Encrypt の証明書失効に関する一連の出来事についてまとめた物です。今回の失効処理の対象となっているかどうかの確認方法等については、以下の記事をご覧下さい。 Let's Encrypt に重大なバグが発覚。該当サイトは2020/3/4 までに対応が必須 更新しました(2020/3/7) 影響の度合いについての記載が正しくなかったので修正 現在の Let's Encrypt の見解が正しくなかったので修正 何が起きているのか？
ls よりも exa を使おう！モダンな Linux コマンド達を紹介 - Qiita
上記の画像を見ると分かる通り、カラフルで見やすいですね。右図のようにディレクトリのツリー表示にも対応しています。さらに --icons オプションを付けると、ファイルタイプに応じたアイコン表示も可能です。 bat 続いて cat コマンドの代替である bat の紹介です。 ファイルの拡張子に応じてソースコードを色付けして表示してくれます。また less のようなページャの機能も持っており、行数の長いファイルを渡すと自動でページャモードで開いてくれます。 hexyl hexyl はバイナリダンプコマンド od の代替コマンドです。bat の開発者と同じ方が開発しています。
今更だけど、SREとは何かについてまとめる - Qiita
バズワード化して何やらふわっと そういう感じ という扱いになっているSREというものについて、何をする人なのかわかりやすく説明したいと思います。 ※概ねSRE本に書いてあるままですが、Googleの中の人とSREについて話をしたり、色々した結果得られた個人的な見解です。 TL;DR SREとは - ソフトウェアエンジニアに運用チームの設計を依頼したときにできあがるもの - 運用業務とその自動化や全体的な効率化をする人たち よくある誤解 SREは運用自体はしないんでしょ？ 違います。ソフトウェアエンジニアであり、運用をする人です。 Continuous Deliveryにあるように自動化のためにも運用をする必要があります。 SREはインフラエンジニアのことでしょ？ 違います。ソフトウェアエンジニアであり、運用をする人です。 SREは運用するだけでしょ？ 違います。半分以上の時間をソフトウェア
MySQL データベースの負荷対策/パフォーマンスチューニング備忘録 インデックスの基礎〜実践 - Qiita
TL;DR この記事に書いた事 二分探索木のお話(前提知識) MySQLのInnoDBで利用されているB+木インデックスの構造と特性 (前提知識) MySQLのClusteredIndex,SecondaryIndexについて(前提知識) カーディナリティについて(前提知識) 実際の負荷対策 検出編 スロークエリ 検出編 その他のクエリ割り出しいろいろ クエリ・インデックスの最適化 explainの使い方と詳細 ケース別実践 単純にインデックスがあたっていないケース カーディナリティが低いインデックスが使われているケース 部分的にしかインデックス/複合インデックスがあたっていないケース 複合インデックスの順序誤りでインデックスが適用できていないケース 複合インデックスの最初がrange検索のケース ソートにインデックスが適用できていないケース ソートにインデックスが適用できていないケース（
書き込みがあるワークロードにおける ZOZOTOWN マルチクラウド構想とその検討停止について - Qiita
この記事はZOZOテクノロジーズ #1 Advent Calendar 2019 23日目の記事です。 昨日の記事は弊チームの inductor による「GKEの内部負荷分散機能を使ってInternal Load Balancerを構築する」でした。面倒で困っているのでGCP様にはなんとかして欲しいものです さて本記事では、残念ながら本番運用には至らなかったのですが、私がここ暫くMLOps業の裏でやっていた「書き込みがあるワークロードにおける ZOZOTOWN マルチクラウド構想」の検討結果について供養のつもりで記そうと思います。 なお、今年は弊社では全部で5つのAdvent Calendarが公開されています。 ZOZOテクノロジーズ #1 Advent Calendar 2019 ZOZOテクノロジーズ #2 Advent Calendar 2019 ZOZOテクノロジーズ #3 Ad
sudo がアレなので doas に乗り替えてみる - Qiita
最初にまとめ 長くなってしまったのでまとめを最初に。 sudoを使うのをやめdoasに乗り替えた doasには必要十分な機能があり、sudoに比べ設定がシンプル doasは元々がOpenBSDプロジェクトのものであり、セキュリティ面でも信頼できる FreeBSDではpkgでインストール Linuxではソースからインストール (記事ではDebian/Ubuntu, CentOSでの例を紹介) doasのソース規模はsudoのそれに比べかなり小さい 最近manやmakeを知らない人が居るという事実を見かけるので、その辺りの利用例も含めて少々回りくどく記述しています。 本記事はSoftware Design誌 2020年1月号 に掲載された「sudoからdoasへ」の内容とほぼ同じもの、というより元の原稿そのものです。ネタを明かすと、元々Qiitaで公開するつもりで書いたのですが、書きすぎてボリ
PostgreSQLアンチパターン：UPDATEの濫用 - Qiita
RDBMS といっても、SQLiteをシングルユーザで使ってたり、ORMやRESTful APIでWrapされた状態で使っていると、SQL問い合わせのできる「ファイル」という感覚になるかもしれません。 その感覚で PostgreSQL を使うとしばしば落とし穴にはまります。 DBMSは大変なのだ DBMSは昔から同時多発の更新要求を矛盾無くさばくトランザクション処理が要件でした。 この要求の苛烈さ・複雑さに思いを馳せるには、"Transaction Isolation Level", "トランザクション隔離性水準", "トランザクション分離レベル" あたりをキーワードにググってみるのがいいでしょう。 たとえばこんなページ http://language-and-engineering.hatenablog.jp/entry/20110104/p1 DBの「トランザクション分離レベル」が必要
さよなら本番サーバー - Qiita
とあるSESの現場では本番リリースの時期が近づいてきており、僕を含めた数人のエンジニアは間に合いそうもない残作業の開発を進めたり、本番で使うためのデータの整備を本番サーバー内で行ったりしていた。ほとんどがその案件のために集められたメンバーだったため特に和気あいあいとするでもなく、エアコンの風の音が響く小さなオフィスの片隅で静かに作業をしていた。 業務上のやりとりもRedmineで行われており、声を発するのもたまにメンバー同士で話をしたり、クライアントから電話がかかってきた時だけ。その日もメールで通知が届いてきており、確認してみるとRedmineで僕が関係しているチケットにコメントが届いているという通知だった。 通知のURLをクリックしてRedmineのチケットを確認してみる。 それによると一旦本番サーバー上に存在するデータの中の一部の主要データをCSV形式で送ってほしいという依頼だった。無
[AWS]CloudWatch Logsの配信タイミングはいつなのか@2019.11 - Qiita
概要 EC2やコンテナ内をステートレスに保つため、ログファイルをCloudWatch Logsに出力することがよくあると思います。 出力させる手順は公式・非公式問わずたくさんありますが、 最新のCloudWatchエージェントにおいて、実際OSがハングアップしたらどこまでログが残るのか、どの程度の間隔でフラッシュされているのか知りたかったので調べてみました。 私は ”最新のCloudWatchエージェント” について知りたかったです。（大事なこと） 結論 CloudWatchエージェント設定ファイル内のlogsセッション 「force_flush_interval」 に 秒単位 で設定する。デフォルトは5秒。 また、この設定にかかわらずバッファ内のログサイズが1MBに達するとフラッシュされる。 詳細は、こちらの公式ドキュメントを参照。 実験 結論は出ていますが、念の為「force_flus
![[AWS]CloudWatch Logsの配信タイミングはいつなのか@2019.11 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/cacb0059f9fe74e625e0f422a61f69524686207c/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCQVdTJTVEQ2xvdWRXYXRjaCUyMExvZ3MlRTMlODElQUUlRTklODUlOEQlRTQlQkYlQTElRTMlODIlQkYlRTMlODIlQTQlRTMlODMlOUYlRTMlODMlQjMlRTMlODIlQjAlRTMlODElQUYlRTMlODElODQlRTMlODElQTQlRTMlODElQUElRTMlODElQUUlRTMlODElOEIlNDAyMDE5LjExJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz04NzY3NjhiODVkMWU3OTQ0YmUxODBkMDVmYTVlNmI2OA%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBOYWNodCZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9MDZmNjdiM2IyMDUwY2UzMzA4NDJhM2YzNjIxYTJhNmI%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3Dd960442256df252ae27eac7d0cdc22d3)
CVE-2019-14287 [sudo] Potential bypass of Runas user restrictions の確認 - Qiita
CVE-2019-14287 [sudo] Potential bypass of Runas user restrictions の確認sudovulnerability sudoで潜在的なRunasユーザの制限バイパスについての脆弱性が出たので、確認した。 summary (TL;DR) 影響を受けるユーザアカウントは限定的 既にsudoers登録がある "どのユーザとして実行できるか"でALLキーワードがある アップデートは実施したほうが良い リスク次第で、緊急 から 次のメンテタイミング、までの間で実施したい。 大半のシステムでは 緊急には該当しない と推定される 脆弱性概要 ALLキーワードで任意のユーザとして実行可能な場合、rootとして実行が可能 例えば user00 (ALL) ALL の場合は、もとから ALLだけなので、rootで実行可能 ALLを制限している場合、例え
![CVE-2019-14287 [sudo] Potential bypass of Runas user restrictions の確認 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/d879c3cb947c2e8cc4fe433cac4b925b724ad8c2/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9Q1ZFLTIwMTktMTQyODclMjAlNUJzdWRvJTVEJTIwUG90ZW50aWFsJTIwYnlwYXNzJTIwb2YlMjBSdW5hcyUyMHVzZXIlMjByZXN0cmljdGlvbnMlMjAlRTMlODElQUUlRTclQTIlQkElRTglQUElOEQmdHh0LWFsaWduPWxlZnQlMkN0b3AmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZzPWEzNDA1NzljYjAwNGUxMGU3MjM2YzljOTFmMzZlMTI3%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBob2dlaHVnYSZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9YThkZWU2YjY3YTAxMDI4ZWU3NWU5MWI4N2UzZjM3Zjg%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3D43a0d450a93d0d4d0549b8c878cd7d1a)
「AWS IAMのマニアックな話」が良本だったので紹介してみる - Qiita
はじめに 今週のQiitaの記事は技術書典で買ったIAM本の書評を書く — nari@BOOTHで好評発売中「GoとAWS CDKで作る本格SlackBot入門」 (@fukubaka0825) September 27, 2019 今技術書典で買ったIAM本、Cognito本、OAuth本を読んでいて今までさらっと流してきた認証認可をがっつり学び直すことができて最高 — nari@BOOTHで好評発売中「GoとAWS CDKで作る本格SlackBot入門」 (@fukubaka0825) September 27, 2019 こんにちわ。Wano株式会社エンジニアのnariと申します。 今回の技術書典7で個人的に一番のお目当だったIAM本を読了したので、宣言通り書評を書いていきます。一言だけ先に行っておくと、「AWSユーザー全員が読んでおく価値のある本」となっていました。 2行でまとめる
もう「公開鍵送ってください」というやり取りは不要だった - Qiita
GitHubに登録している鍵ペアの公開鍵は公開されてる 実は、GitHubに登録している鍵ペアの公開鍵は公開されてるのです。 GitHubのユーザーページのURLの後ろに「.keys」をつけると、その人の公開鍵文字列がDLできます。 アカウントがy-tsuzakiなら https://github.com/y-tsuzaki.keys です URLにアクセスすると公開鍵の文字列が表示されます。 このURLを使うことで、 GitHubユーザーには、わざわざメールやチャットで「公開鍵送ってください」と言わなくていいのです。 これは捗りますね。 authorized_keysに設定する方法 追記する方法 コメントで教えてもらいました。 @grohiro さん @ktooi さん ありがとうございます！
たのしく学ぶLinuxカーネル開発(第一回): `rm -rf /`実行時にカーネルパニックさせる - Qiita
はじめに Linuxカーネル開発を学ぶためにhello worldモジュールからはじめて少しづつ強化する記事を過去にいくつか書きました。これはちゃんとやれば身に付くことは身に付くのですが、非常に地味なので、よほどカーネルに興味を持っている人以外には退屈でしょう。そこで、目的をもって特定の機能をカーネルならではの方法で実現する記事を書けば面白いのでは…となったのでここに初回を書くことにしました。 対象読者はCライクなプログラミング言語での開発経験がある人です。Cのポインタがわかればなおよし。もしできればOSカーネルについての基本的な知識も欲しいです。 背景 UNIXが誕生してから現在に至るまでrm -rf /によって全ファイルをぶっ飛ばす事件が後をたちません。GNUのcoreutilsに入っているrmではルートディレクトリ("/")への操作を特別扱いして容易に悲劇を起こさなくするpreser
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
proftpdでSFTPを受ける - Qiita
tarコマンドのかわりにpaxコマンドを使う - Qiita
【SRE Next 2020】発表資料まとめ - Qiita
crontabを捨てsystemdに定期実行を任せよう。 - Qiita
本番環境でやらかしちゃった人 Advent Calendar 2019 - Qiita
