現代ITインフラの王道をゆくLinuxパッケージ管理の基本構成 | 外道父の匠
RedHat系におけるRPMパッケージを扱うYUM、Debian系におけるDEBパッケージを扱うAPT、これらはサーバー管理において重要なわけですが、絶妙な度合いで、おざなりに扱ってもわりとなんとか運用出来てしまう感があります。そのため今一度、こんな感じが今風のスタンダードじゃないっすかね（ｷﾘｯ という構成を説明してみます。 ぶっちゃけ、たいしたことないネタの集合体なので、タイトルに下駄を履かせました。 そもそもパッケージは必要なのか 言うまでもなく必須です。理由は、インストール物のファイル管理が容易になるのと、インストール時間を短縮できるからです。既存のパッケージでconfigureオプションが物足りない時や、RPMパッケージが存在しない場合は作成することになります。 最近はプロビジョニング・ツールによって全て自動化できるので、超簡素なコンパイルのものはレシピに落とし込んで終わりにした
Consulをfpmでrpm化する - Qiita
https://github.com/udzura/consul-rpm-builder 公式にはバイナリのみを提供しているみたいなので、もう少し楽なように各種ディレクトリや展開済のWeb UIをrpm化しておいた。Puppet/Chefのコード数が減って便利。 サードパーティのrpmは他にもあるのだが、個人的に でやっていきたいので自分で雑に書いた。 fpm が便利 fpm は各プラットフォームのパッケージを簡単に作成できるコマンド。Rubyのgemで提供されている。 適当なrootfsにディレクトリとファイル構成を構築する そこを指定して、後は適当にメンテナ名などの設定を入れつつコマンドを放つ Goの場合、バイナリ一発＋設定のディレクトリやファイル ぐらいしか必要ないのでこれだけでできる（rpmを作る場合は別途 rpm-builder が必要だった）。 fpm -s dir -t rp
Docker を用いた rpm / deb パッケージ作成の継続的インテグレーション - ゆううきブログ
サーバ管理ツールのエージェント みたいなソフトウェアをインストールしやすくするために、rpm / deb パッケージを作りたい。 しかし、rpm / deb パッケージ化するためには、それぞれ CentOS(RedHat)、Debian(Ubuntu) 環境でパッケージ化することになる。 社内ではこれまでパッケージ化の専用ホストがいて、そこで spec ファイルや init スクリプトを置いて rpmbuild コマンドとか debuild コマンドを叩いてパッケージを作成していた。 さらに、アプリケーションエンジニアからインフラエンジニアに依頼するという形をとっていた。 この方法の問題点として、以下の3つがある。 spec ファイルや init スクリプトなどをプロジェクトの Git リポジトリで管理しづらい。つまり、レビューとかがやりにくい。 リリースフローを自動化しづらい。具体的には
RPM のビルド環境を整えるときの Tips | Carpe Diem
RPM のビルド環境を整えるとき、先日紹介した rpmdevtools を使うと、とても簡単に RPM のビルド環境を作ることができます。 具体的には、rpmdevtools に含まれている rpmdev-setuptree というコマンドを実行するだけです。 $ /usr/bin/rpmdev-setuptree そうすると、$HOME/rpmbuild ディレクトリが作成され、次のような $HOME/.rpmmacros ファイルが作成されます。 次のファイルは、CentOS 5.3 x86_64 のときに作成される .rpmmacros です。 %_topdir %(echo $HOME)/rpmbuild %_smp_mflags -j3 %__arch_install_post /usr/lib/rpm/check-rpaths /usr/lib/rpm/ch
RPMビルド時のデフォルトファイル名を変更する - 気ままにインフラエンジニア
自前でrpmをビルドした場合、出来上がるrpmのファイル名はspecファイルによって決まる。 specに指定がない場合、rpmbuildのデフォルトのパラメータが利用され、大体の場合 xxxxx-1.0.1-1.x86_64.rpm のようなファイルが出来上がる。いくつかのOSが混在している環境でrpmをビルドすると、ファイル名が重複してしまいややこしい。 specを編集したりする方法もあるが、specファイル入のアーカイブからspecだけ取り出して編集するのは面倒であるし、できたファイルをいちいちrenameもしたくないので、rpmbuildの設定ファイルを変更する。 /usr/lib/rpm/macrosを編集し、 %_build_name_fmt %%{ARCH}/%%{NAME}-%%{VERSION}-%%{RELEASE}.%%{ARCH}.rpm から %_build_nam
checkinstall でインストール
自分では spec が書けなくて…。そういう人にお薦め、Checkinstall。 tar ball だけが配布されているパッケージの場合、もちろんそのままインストールしても良いのですが、せっかくの rpm パッケージ管理システムがあるのだから、できれば rpm パッケージでインストールしたい。 ちょっと試して期待外れだったり、不要になったら -e でアンインストールも簡単にできるし、バージョン管理も確実になる。spec さえ自分で書ければ世話は無いのですが、そもそもそこまでのスキルは無いという私にとってあまりにありがたいアプリケーション。 rpm 専用ではありません。パッケージ作成の際に Slackware の tgz 形式や deb 形式も選べます。 この文書では 2010 年 3 月最新のパッケージ checkinstall-1.6.2.tar.gz について解説します。checki
CentOS6.2にMySQL5.5公式バイナリをインストール時、mysql-libsの依存関係を気にしなくてよくなってた件 - 気ままにインフラエンジニア
半日かかったのに若干しにたい。 CentOS6.2にMySQL公式のバイナリをインストールするしようとすると、下記のような依存性エラーが発生していて、解決を先延ばしにしていた。 Scientific LinuxにMySQL5.5をインストール - cyber_snufkinの日記 postfixはどうしても入ってしまうし、削除するのも気持ち悪いし、remiは本番には使わないことにしているのでどうしようか試行錯誤していたが、結局RHEL系のパッケージ名が問題なのでrpmを直しましょうということになった。 http://bugs.mysql.com/bug.php?id=63433 rpmrebuildというツールでrpmを再パッケージするなどして、できた！と思っていたところだったのだが…先延ばしにしている間にMySQLの5.5.23がリリースされていたので、リリースノートをチェックしてみた。
CPANモジュールをスクリプト一発で依存解決しつつrpm化する - とあるはてな社員の日記
少し前にmizzyさんに そういえば、まっさらなサーバを30分で本番投入できるようにする で stanaka さんが「CPANの依存関係を解析してrpm化する手製スクリプトで、CPANモジュールのrpm化が、ほぼ自動化されています」と書いてるんだけど、これって公開してくれないのかなー。 HowToRpmizeCpanModules - mizzy.org - Trac と突かれたので、githubで公開してみます。 http://github.com/stanaka/cpan-dependency/tree/master 突かれたついでにmizzyさんに軽く動作確認してもらったところ、それなりに動いているようです。また、はてなでは、このスクリプトを利用して、日々それなりの数のCPANモジュールのrpm化を行っていますので、だいたいうまく動くのではないかと思います。 CentOSやFedor
HowToRpmizeCpanModules - mizzy.org - Trac
Wassr で ZIGOROu さん や hidek さん とやりとりした内容をまとめてみます。 CPAN モジュールの rpm パッケージ作成なんですが、自分はRPM::Specfile に付属している、cpanflute2 を基本的に使ってます。 cpan2rpm の方がメジャーだとは思うんですが、オリジナルのダウンロード用FTPサイトが接続できないのと、吐き出す SPEC ファイルが微妙な感じがするので、なんとなくイヤで使ってないんですが、それ以外はそんなに明確な理由もなく、cpanflute2 の方を使ってます。 ただ、cpanflute2 には以下の問題点があります。 依存関係を自動的に解決してくれない（これは cpan2rpm も同じ） モジュールの tar ball を自分で取得しないといけない（cpan2rpm はsearch.cpan.org から取得してくれる） なので
toshiki-net - ぶろぐっぽいなんか : CPANのモジュールをAPTとyumで管理する方法(1) by watanabe
このエントリで書いたんだけど CPANモジュールをアンインストールするぐらいならパッケージにしてしまえという話。 で、私がやってる方法をまとめてみることにした。 概要（？） APTはsvn-buildpackage + debpool yumはビルドしたrpmとrepodataをsubversionに放り込んで管理する パッケージ化はAPT -> rpmの順で作成する（別にRPMだけ作ってもいいけどRPMだけだとAPT作るの忘れるので） これはパッケージツールの関係でsvn-buildpackageはソースをそのままレポジトリに放り込めるが、rpmはsrc.rpmのような形でしかソースを取っておけないため 配布はAPT、yumともにHTTPで（設定が簡単だから(w） svn-buildpackage ぐぐって(w とか言うとあんまりなので大まかな手順を # 作業ディレクトリに移動 % cd
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
git.centos.org
ウノウラボ Unoh Labs: rpmパッケージを作ろう
『Perl モジュールからの RPM 作成方法』へのコメント