Red Hat’s commitment to open source: A response to the git.centos.org changes
I spent a lot of time walking this weekend thinking about the reaction from our industry to my last blog post. We’ve been called evil; I was called an IBM exec who was installed to turn Red Hat closed source — and that’s only the “nice” stuff. So let’s clear things up. My name is Mike McGrath, and I’m the Vice President of Core Platforms Engineering at Red Hat. I’ve been here for 16 years, and bef
POSIX 準拠のシェルスクリプトでは find | xargs よりも find -exec {} + を使うべき！ - Qiita
POSIX 準拠のシェルスクリプトでは find | xargs よりも find -exec {} + を使うべき！ShellScriptBashshellPOSIX はじめに find の出力を xargs にパイプで渡すというのはよく見かける使い方ですが、find -print0 | xargs -0 が使えない POSIX 準拠のシェルスクリプトでは find -exec {} + を使った方が良いです。安全かつ十分に速いからです。よく見かける -exec {} ; ではなく -exec {} + ですので間違えないようにしてください。多くのケースでは + の方が優れているのですが ; ばっかり使われているのを見ると、意外と知られてない気がします。 少しだけ予備知識として、-exec {} ; は -exec {} \; と ; をバックスラッシュでエスケープするのがよく見る使い方
ここが変だよ「WSL2」 自作ディストロ開発で発見した知られざる“バグ”と“事実”
Kernel/VM探検隊は、カーネルやVM、およびその他なんでもIT技術の話題ジャンルについて誰でも何でも発表してワイワイ盛り上がろうという会です。佐伯氏は、WSL2においてあまり知られていないバグと事実について発表しました。 自己紹介 佐伯学哉氏（以下、佐伯）：Kernel／VM online part4ですが、「ここが変だよWSL2」という日本語タイトルで、スライドは英語になっていますが、WSL2（Windows Subsystem for Linux 2）に関するいろいろなことを話します。 アウトラインですが、基本的にはランダムトークで小ネタをたくさん話します。なので、WSLとは何かとか、技術的には興味深いけれど公式のドキュメントがきちんと説明してること、つまりWSLgですね。技術的にはおもしろいのですが、公式が全部説明しているので、ここでは一切触れません。このトークは、僕が個人的に
VcXsrv Windows X Server
Windows X-server based on the xorg git sources (like xming or cygwin's xwin), but compiled with Visual C++ 2012 Express Edition. Source code can also be compiled with VS2008, VS2008 Express Edition and VS2010 Express Edition, although current project and makefile are not fully compatible anymore. Versions starting from 1.14.3.0 are not compatible with Windows XP anymore.
Windows 10のコマンドプロンプトからWSL上のLinuxコマンドを呼び出す（バージョン1803対応版）
コマンドプロンプトからWSLのプログラムを呼び出す Windows 10に「WSL（Windows Subsystem for Linux）」をインストールすると、Linux向けのプログラム（バイナリファイル）をそのまま実行することができる。 例えばテキストデータの処理では、awkやsed、tr、cut、sort、uniq、～grep、head、tail、……など、非常に多くの「定番」と呼ばれるツールが利用されるが、Windows OSではsortぐらいしか用意されていなかった。また文字コードがUTF-8になると、標準のWindows OSのツールだけではほぼどうしようもない。これまでは、ほとんどの場合、こうしたツール類をWindows OS向けに誰かがリリースしてくれるのを待つしかなかった。しかしWSLを利用すれば、これらのツールがそのまま利用できるので、入手に悩む必要はない。 具体的な
yum｜yum リポジトリを作成する
yumのリポジトリの作成手順を説明します。createrepo コマンドを使ってリポジトリを作成します。 Last Update : 2015年04月02日 yum｜yum のリポジトリを作成する 項目 createrepo コマンドのインストール パッケージの配置 リポジトリの作成 作成したリポジトリへアクセスする リポジトリの内容を更新する場合 1. createrepo コマンドのインストール yum のリポジトリを作るには、createrepo コマンドを使います。createrepo コマンドは以下のようにしてインストールします。 # yum install createrepo 2. パッケージの配置 リポジトリは、任意のパスに作成できます。ローカルからしかアクセスできない場所に作成してもいいし、apache等のWEBサービスの管理下にリポジトリを作成すれば、HTTP／HTTP
LVMの情報を表示するには ― ＠IT
LVM（Logical Volume Manager：論理ボリュームマネージャ）は、複数のパーティションを1つのディスクとして利用するためのディスク管理機能だ。Fedoraは標準でLVMをサポートしており、Anacondaによるインストールでは、デフォルトでLVMが設定される。
Linux 仮想マシンの OS ディスクの拡張方法 (ARM編)
最終更新日：2016/09/07 こんにちは。Microsoft Azure テクニカル サポートの乾です。 Microsoft Azure 上の多くの Linux 仮想マシンの OS ディスク (/dev/sda1) は 30 GB に設定されています。ディスクを追加してマウントすることは容易ですが、OS ディスクの拡張が必要となることもあるかと思います。今回は、リソース マネージャー デプロイ モデルの CentOS6.7 の仮想マシンの OS ディスクの拡張方法をご案内いたします。ディストリビューターやバージョンが異なる仮想マシンで本手順を実施いただく場合、実行できるコマンドが異なる場合がございますので、ご注意ください。 ※本情報の内容（添付文書、リンク先などを含む）は、更新日時点でのものであり、予告なく変更される場合があります。 利用シーン OS ディスク (/dev/sda1)
process-book
この文書はなんですか？ この文書は*nix系のシステムにおけるプロセスやシグナルなどについて説明することを目的に書かれました。「プロセスとかよくわかってないからちゃんと知りたいな」みたいなひとたちが想定読者です。 書いているあいだは gist で管理されていたのですが、ボリュームが大きくなったので github で管理するように変えました。 目次 導入 プロセスの生成 プロセスとファイル入出力 ファイルディスクリプタ preforkサーバーを作ってみよう ゾンビプロセスと孤児プロセス シグナルとkill プロセスグループとフォアグランドプロセス epub と pdf epub化したもの、pdf化したものが release ディレクトリに入っています。thanks to mitukiii & moznion！ ライセンス この 作品 は クリエイティブ・コモンズ 表示 - 継承 3.0 非移
技術/UNIX/なぜnohupをバックグランドジョブとして起動するのが定番なのか？(擬似端末, Pseudo Terminal, SIGHUP他) - Glamenv-Septzen.net
ホーム 検索 - ログイン | | ヘルプ 技術/UNIX/なぜnohupをバックグランドジョブとして起動するのが定番なのか？(擬似端末, Pseudo Terminal, SIGHUP他) [ Prev ] [ Next ] [ 技術 ] 何をいまさら当たり前の事を・・・と思われるだろう。 $ nohup long_run_batch.sh & SSHからログアウト後も実行を続けたいバッチジョブを、"&"を付けてバックグラウンドジョブとしてnohupから起動するのは定番中の定番である。 しかし、「nohupを使わなくても実行を続けることが出来る」やり方があったり、さらには「nohupを付けてもログアウト時に終了してしまう」パターンがあるとしたらどうだろう？ そして、ある日あなたの後輩や同僚がこれらについてあなたに質問してきたら、あなたはどう答えるだろうか？ 「Web上で検索したら見つか
Site has been shut down
The end of the road In July 2013, I released a bash script that would allow RHEL/CentOS 6 users to continue to run the latest Google Chrome release, despite official support for that platform being dropped from Google Chrome 28 onwards. Sadly, the release of Google Chrome 59 (and later versions) meant a switch to GTK+3, which was impossible for my script to workaround on RHEL/CentOS 6. Hence, this
rm -rfしちゃったけどどうする
rm -rf remains rm -rfの後に残りしもの 遊びのために、筆者は新しいLinuxサーバーを立ち上げて、rootでrm -rf /を実行して、何が残るかをみてみた。どうやら、今のrmというのは筆者のようなアホを相手にしなければならない未来に生きているようなので、実際に実行するには、--no-preserve-rootをつける必要があった。 # rm -rf --no-preserve-root / かかるおろかなる行為の後では、 /bin/ls /bin/cat /bin/chmod /usr/bin/file のような、偉大なるツールのたぐいはみな消え失せてしまった。まだ、ssh接続とbashセッションは生きているはずだ。つまり、bashの組み込みコマンドであるechoとかは残っているということだ。 Bashマクガイバーたれ root@rmrf:/# ls -bash: /
SPDYとLinuxの間でGoogleマップがハマった落とし穴 - ぼちぼち日記
tl;dr 書いていたら思わず長文の大作になってしまいましたので、プロトコルオタ以外の方は文章の多さに退屈されるかと思います。GoogleマップサービスでSPDYの問題が発覚し、GoogleがLinuxカーネルに修正を加えて対応したというお話です。将来 Linux + nginx + SPDY を使いリバースプロキシでサービス運用を検討されている方は参考になるかもしれません。 1. はじめに、 プロトコルに執着する年寄りエンジニアの老害が叫ばれて久しい。 年甲斐もなく自分好みのパケットを追っかけるおやじエンジニアの姿を見て眉をひそめる若者も多いと聞く。 そんな批判に目もくれず、今日も一つ、プロトコルオタのネタをブログで公開したいと思いますw 今回はちょうど１年ほど前に書いたブログ記事 「GmailがハマったSPDYの落とし穴」の続編です。といっても今度の舞台は、Googleマップ。ネタ元も
コンソールから切れたプロセスを標準出力につなげなおす - 絶品ゆどうふのタレ
不慣れな環境を不意にいじった時にあるあるネタ。 とりあえずー とか言って勢いで書いたsetupスクリプトを実行してみたら意外と時間かかって、 ちょっと目を離した隙にsshの接続が切れちゃいました！ 。。。ありますよね。ほんとよくありますよね。 そうなる予感はあったんだ なんて後の祭りです。ふとした油断から、screenもnohupすらも使わずにやってしまって、こんなことに。 shellがHUPしなかったからプロセスは生きてるものの、ログが見れないから進行状況がわからない。 うまく行ってるのかどうかモヤモヤした気持ちのまま、プロセスが終わるのをじっと待つ。。。 まぁ実に切ないです。 こんな時、いつも思うこと。 このプロセスの出力、もっかいstdoutに繋げられたらいいのに。。。 はい。というわけでつなげましょう。 長い前座ですみません。 切り離したプロセスを用意 #!/bin/bash wh
FAQ/CentOS6 - CentOS Wiki
1. I used to use the boot.iso image to do network installations. Where has it gone ? Starting with this release, upstream decided to remove boot.iso from the images/ directory and ship it as a separate, stand alone media. Due to the large size of this image, we have decided to do the same. The network installation disk image is named netinstall.iso and can now be found only in the isos/ directory,
kernel: TCP: time wait bucket table overflow の解消とTIME_WAITを減らすチューニング - 気ままにインフラエンジニア
整理がてら。 httpdが動いているあるホスト上で、 /var/log/messages に以下のようなメッセージが出ていた。 kernel: TCP: time wait bucket table overflow kernel: printk: 50078 messages suppressed. "netstat -tna |grep TIME_WAIT"すると、10万以上の数でTIME_WAITが出ている。これを解消するまでの流れ。 そもそもこの値は、カーネルパラメータの net.ipv4.tcp_max_tw_buckets で設定されている。デフォルトは16384。 （↑の通り、エラーが出た環境では既にかなり大きな値が設定されていたのだが。） /proc/sys/net/ipv4/tcp_max_tw_buckets システムが同時に保持する time-wait ソケットの最大
Linux サーバでの「Too many open files」対策について - akishin999の日記
Linux サーバでの「Too many open files」エラー対策について調べたのでまとめてみました。 確認した OS は CentOS 5.9 と CentOS 6.3 です。 「Too many open files」は Linux でプロセスが開けるファイルディスクリプタの上限に達してしまうと発生するエラーです。 「ファイルディスクリプタ」という名前ですが、 Linux ではソケットもファイルディスクリプタなので、ファイルを開いた場合だけでなく、ソケットを使って通信を行う場合にもファイルディスクリプタが使用されます。 そのため、Apache や Tomcat などで高負荷なサイトを運用している場合などには、比較的遭遇する確率の高いエラーではないでしょうか。 このエラーを回避するため、プロセスがオープンできるファイルディスクリプタの上限を変更します。 まずは以下のコマンドを実行
地雷だらけのrsyncを理解する。 - こせきの技術日記
rsync -avz --exclude-from=pattern-file --delete SRC/ DEST SRCの末尾に/をつける。たいてい必要。 SRCスラッシュの有無は、mv SRC DEST と mv SRC/* DEST の違いと一緒。スラッシュの後ろに*が省略されているものと考える。 DESTのスラッシュの有無は関係なし。 --dry-run(-n)をつけて試す。 SRC、DESTともローカルのディレクトリを指定して試す。 DESTはまず空ディレクトリで試す。DESTが同期済みだと何が更新されるのか正確にわからないので。 --list-onlyをつけてファイル一覧を得る。 DESTを省略してファイル一覧を得る。 --list-onlyと同じ？ --deleteはDESTのファイルを根こそぎ削除する可能性がある。注意。 --delete-excludedは使わない。--d
ほげめも: etckeeper で多数のホストの /etc を集約・共有する
etckeeper で多数のホストの /etc を集約・共有する etckeeper を使うと /etc の内容と変更履歴を git などのバージョン管理システム (VCS) で手軽に管理できますが、素の etckeeper には /etc の変更をローカルのリポジトリにコミットする機能しかなく、git のような分散 VCS の特徴を生かすことができません。 しかしながら etckeeper と git の組み合わせで、リモートリポジトリとブランチをうまく設定し一工夫を加えることで、多数のホストの /etc の変更をひとつのリポジトリに集約し共有することが簡単にできるようになります。 準備 まずは etckeepr を git で動かしてください。 Debian squeeze では apt-get install etckeeper とするだけで git と etckeeper がインス
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM Developer
