「企業システムに必要な自動化」は、なかなか大きなテーマで、すぐに答えが出るものではありません。この連載では、最初に取り組むべき課題として「サーバー構築の自動化」をテーマに技術解説を進めていきます。まず、身近な具体例を紹介しましょう(別掲記事「IT研修センター」の自動化事例も参照)。
TL;DRFireFoxでchrome.*()系APIを使うとき、content_scriptだけpromiseなAPIで、ほかはコールバックな模様 概要 そもそも、 - FireFoxはChrome拡張機能互換の一環として、chrome.storage.local.get()といったchrome.*()系APIを実装している https://developer.mozilla.org/ja/docs/Mozilla/Add-ons/WebExtensions/API/storage/StorageArea/get > この API は Chromium の chrome.storage API に基づいています。 - MDNのドキュメントではchrome.*()系APIはコールバックで非同期を返すものとなっている (前述のURLにて。2024年現在も) - Chromeブラウザのchro
Site functionality and performance. These cookies are required for NGINX site functionality and are therefore always enabled. They contain no identifiable information. Social media and advertising. Cookies that help connect to social networks, and advertising cookies (of third parties) to help better tailor NGINX advertising to your interests
何がLinuxデスクトップを殺したか(What Killed the Linux Desktop 日本語訳) 要約すると、(a) 第一の要因:物事があまりに早く変化し、オープンソースも独占ソフトウェアも同じように壊れる。(b) Linux ディストリビューション間の非互換性。 これがデスクトップ分野で Linux をターゲットとしようとするサードパーティの開発者のエコシステムを殺した。一度は挑戦して、「トップ」ディストロや寛容な人なら「トップ3」ディストロをサポートするのに最善を尽くすだろう。それで知ることになるのは、6ヵ月後にはそのソフトウェアがもう動かないということだけ。 何か覚えのある感覚。僕(ら)はサーバー用OSとしてDebianを選ぶのにも同じような考えをしているなと思いました。 Linuxはサーバー分野では成功して、沢山のサードパーティー開発者(僕も)に使われている。サーバー分
Twitter mongrelP: @tasukuchan グニャラくーん、ニコ百の鯖がEeePCという話が持ち上がってますがただの監視用ですよね(しんぱいそうなめでみている) http://twitter.com/mongrelP/status/1524183917 ニコニコ大百科のアーキテクチャについてメモしておきます。 本当は、このネタでRuby Kaigiに申し込もうと思ったけど、すっかり忘れていたのでエントリを起こしておきます。Rubyあんま関係なかったし。 全てのリクエストを受付、セッション情報も保持するEeePC 次世代サーバプラットフォーム EeePC ニコニコ大百科宛ての全てのリクエストは、全てEeePCに送られます。 実物の写真を載せておきます。 EeePCは2台稼動しており、1台はホットスタンバイです。 EeePCは、SSDとUPSを備えた次世代サーバプラットフォーム
今までの自宅サーバー 今まで、自宅サーバーはZBOXNANO-AD10という超小型ベアボーンを使っていました。超小型なので設置場所に困らず便利だったのですが、メモリスロットが1つしかないためメモリ8GBまでしか詰めませんでした。また、CPUのAMD Fusion E350 APUは低電圧ですが、その分性能があまり良くないので、ブログもアクセスアップしていることだし、サーバーを増強することにしました。 ZBOXNANO-AD10 Shuttleサーバー 今回も筐体はベアボーンを使いました。ShuttleのSZ77R5です。マザーボードとPCケースからの完全な自作でも良かったのですが、自宅が1LDKという制約があって、MINI-ITXの筐体しか置けない。MINI-ITXでメモリスロットが4個あるマザーボードはなく(全部最大2個)、メモリスロットが4個あってIntel Ivy Bridge Z7
CentOSとは、RHEL(Red Hat Enterprise Linux)との完全互換を目指したフリーのLinuxディストリビューションです。 CentOSサーバー構築マニュアル.comは、CentOS5,CentOS6,CentOS7で安定した自宅サーバーの構築手順を紹介しています。 初心者から上級者の方まで、コマンドを入力するだけで安定した自宅サーバーを構築することができます。 VPSに対応しています。 CentOS7 サーバー構築手順 初期準備 インストール前の初期準備 独自ドメイン取得 DNS情報設定 ダイナミックDNS取得 DNS情報設定 OSインストール CentOS7 インストール WindowsクライアントからTera TermでSSHログイン 初期設定 CentOS7 インストール後の設定 Tera Termで公開鍵認証 RPMforge EPEL ELRepo Re
morimorihogeです.新年一発目の投稿です.最近木曾が改二になりました. Web開発に限らず,UNIX系で動作するシステムの開発・運用に携わっていると常にターミナルクライアントを開いているということが多いかと思います.Web開発やサーバインフラの構築・運用をやっていると,自分のローカルPCだけではなく,リモート上の別マシンに接続し,テストサーバや本番サーバでコマンドを打って作業する機会が多くなります. そんな中「ローカルマシンのコンソールだと思ってrmしたら実は本番系サーバだった」「なんか色々実行してて処理が怪しいなと思ったら別のサーバだった」という思いをしたことがあるのは僕一人だけじゃないと思います. 今回はこういった問題を防止するために僕が普段から守っているターミナルの運用ポリシを紹介してみようと思います.あまり技術的な話はないですが,普段開発・運用を仕事としてしていく上でのノ
仕事でagを利用していた時に出会ったバグを、先輩たちの力を借りてなんとかした話です。 先に結論を書くと、業務に用いていたagのバージョンが古いのが原因のようでした。version 0.15より古いとlockの実装に問題があるようです。 以下、問題の発覚からなんとかするまでの記録です。 発端 agが途中で止まる 時折、agのファイル操作が先へ進まなくなってしまう不具合がありました。 操作中に対象ファイルのロック状況が変わるとデッドロックが発生しているのでは?と想像。 気になってstraceでプロセスにアタッチすると、以下で停止していることが分かりました。 [pid 4589] futex(0x80517e4, FUTEX_WAIT, 32159, NULL FUTEX_WAIT futex(2)を引くと、futex(2)の書式に対する操作FUTEX_WAITの説明があります。
本特集では、次世代DNSサーバソフトウェア「Unbound」にフォーカスし、機能や特徴を解説しながら、実際の運用ノウハウについてお届けします。第1回目はUnboundの基礎知識について解説します。 Unboundの概要 UnboundはBINDの代替を目指したDNSキャッシュサーバです。2008年5月20日に正式版1.0がリリースされました。オープンソースのソフトウェアとして公開されており、ライセンスはBSDライセンスです。 UnboundはNLnet Labsにより開発と保守が行われています。UnboundはVerisign labs、Nominet、Kirei、ep.netによりJavaで開発したプロトタイプを、NLnet LabsがCで実装し直したものです。ちなみに、NLnet Labsはルートサーバとしても利用されているDNSコンテンツサーバのNSDも開発しています。リリースされた
2008年5月にリリースされたばかりの新しいDNSリゾルバ「Unbound」は、シンプルで高速に動作するうえに、話題となっているDNSキャッシュポイズニング攻撃への耐性も高いという特徴を備えています。(編集部) 株式会社 サードウェア 岩崎 登 2008/10/17 DNSとは、そしてUnboundとは UnboundはオランダのNLnet Labsが開発しているDNSキャッシュサーバ(DNSリゾルバ)である。2008年5月に正式版のバージョン1.0.0がリリースされ、BSDライセンスの下、オープンソースソフトウェアとして公開されている。 NLnet Lab.は、DNSコンテンツサーバ「NSD」の開発元としても知られており、開発元の信頼も高い。 インターネットでは、IPアドレスによって、アクセスするサーバ(ホスト)を特定している。IPアドレスとは、いわゆる郵便番号のようなもので、インターネ
マシンの調達 今回は、自宅サーバーを作るにあたって気を付けるべき点や考慮すべき点をまとめました。 自宅サーバーとなるマシンを調達する上でよくあるパターンとして「新しいPCを買ったので古いPCが余った。しかし特に使い道もないのでLinuxか何かを入れてサーバーにでもしてみようか」というものがあります。これは半分おすすめし、半分はおすすめしません。 半分おすすめする理由としては、サーバー構築を経験するよい機会だからです。サーバー構築するという機会はそうめったにあるものではありません。自宅にたまたま余ったマシンがあり「取りあえず自宅サーバーにでもしてみるか」という手軽さはサーバー構築の経験を積むのによい機会となるでしょう。 一方、半分おすすめしない理由としては、PCが古いため壊れやすいこと、そして電気効率が悪くて24時間稼働すると電気代が非常に高くなる可能性があることです。サーバーとして24時間
インターネットサービスプロバイダ(ISP)のサーバからメールを取得するように普通のやり方で電子メールクライアントを設定するだけでは、十分に対応しきれない状況もある。たとえば、デスクトップPCの補助用にノートPCを導入している場合や、ときおりパートナーのコンピュータを使って自分のメールを読む場合だ。そうした状況では、自分が使うすべてのクライアントマシンでメールの同期を取るという課題にぶち当たる。POP3(Post Office Protocol)の代わりにIMAP(Internet Mail Access Protocol)を使うという手もあるが、その場合はすべてのメールをISPのサーバにためておく必要があり、それはそれで問題が残る。ここでは、自分のネットワーク上にメールの読み出しと保管用のサーバを1台セットアップすることで、メールクライアントが何台あってもメールを同じように扱えるようにする
nginx documentationIntroduction Installing nginx Building nginx from Sources Beginner’s Guide Admin’s Guide Controlling nginx Connection processing methods Setting up hashes A debugging log Logging to syslog Configuration file measurement units Command-line parameters nginx for Windows Support for QUIC and HTTP/3 How nginx processes a request Server names Using nginx as HTTP load balancer Configur
nginx-1.26.1 stable and nginx-1.27.0 mainline versions have been released, with fixes for vulnerabilities in HTTP/3 (CVE-2024-32760, CVE-2024-31079, CVE-2024-35200, CVE-2024-34161). nginx-1.26.0 stable version has been released, incorporating new features and bug fixes from the 1.25.x mainline branch — including experimental HTTP/3 support, HTTP/2 on a per-server basis, virtual servers in the str
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く