2019年5月31日 Fedora、RPMパッケージの圧縮アルゴリズムをxzからZstdに変更へ | gihyo.jp
Linux Daily Topics 2019年5月31日Fedora、RPMパッケージの圧縮アルゴリズムをxzからZstdに変更へ リリースされてからちょうど1ヵ月が経過した「Fedora 30」だが、プロジェクトチームはすでに次期リリース「Fedora 31」に向けて数多くのアップデートを検討中だ。その中でも比較的大きな動きとして、RPMパッケージの圧縮アルゴリズムを長年使ってきたxzからZstdへと変更する可能性が強くなってきている。 Changes/Switch RPMs to zstd compression -Fedora Project Wiki この提案を行ったのはRed Hatでプリンシパルソフトウェアエンジニアを務めるDaniel Machで、現在、バイナリRPMの圧縮に使われているxz（レベル2）をZstd（レベル19）に変更することで、解凍時に劇的なパフォーマンス向
DockerとMakeを利用したRPMパッケージのビルド環境 | メルカリエンジニアリング
SREチームの@cubicdaiyaです。今回はDockerとMakeを利用したメルカリの自作RPMパッケージのビルド環境について紹介します。 メルカリの自作RPMパッケージ事情とVagrant、そしてDocker メルカリの開発およびプロダクション環境では現在CentOS6と7を利用しており、随時CentOS7へ移行中です。そのため、自作RPMパッケージをビルドする際はCentOS6と7向けにそれぞれビルドしています。ビルドしたパッケージはyumリポジトリサーバにアップロードした後、必要に応じてyumでインストール、Ansibleのplaybook化を行います。 RPMパッケージの作成はSREチームのメンバーが行っており、各自のローカルマシン上において make {パッケージ名} を実行するだけでCentOS6と7向けのRPMパッケージをビルドできる環境をDockerで構築しています。
Introducing Dockercast – the Docker Podcast | Docker Blog
Learn how to use OpenPubkey to bind public keys to workload identities using GitHub Actions and Docker. And find out how Docker is using OpenPubkey with GitHub Actions to sign Docker Official Images and improve supply chain security. Learn four best practices that your teams can implement to maintain a secure and reliable software delivery process with Docker Hub in Google Cloud. With these guidel
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
革命の日々！ おまえら rpmdev-setuptree を使えという話
いままで、rpmbuildするときに mkdir -p ~/rpmbuild/{BUILD,BUILDROOT,RPMS,SOURCES,SPECS,SRPMS} して、 echo '%_topdir %(echo $HOME)/rpmbuild' > ~/.rpmmacros とかやってたんだけど、それはもう古いらしい。 % yum install rpmdevtools % rpmdev-setuptree すると、上記の両方をやってくれるのに加えて .rpmmacrosに並列処理設定を追加してくれる。 こんな感じ %_topdir %(echo $HOME)/rpmbuild %_smp_mflags %( \ [ -z "$RPM_BUILD_NCPUS" ] \\\ && RPM_BUILD_NCPUS="`/usr/bin/nproc 2>/dev/null || \\\ /u
インストール対象のRPMが依存しているパッケージを丸ごとダウンロードする - humangas's blog
なんでそんなことをするのかというと。。。 自分はインフラエンジニアやってますが、お仕事だと、ネットに出れないサーバがいたり、そもそもインストールは環境管理側のセンターに任せろ。でも、そのための手順とモノは用意してね。ということが結構ある。 なので、依存パッケージごと丸ごとDLできればすげぇ楽なんです。で、今回の方法が大いに役に立つ。 やり方の結論は、yum downloadonly（yum の依存関係ファイルを全てダウンロードだけしてくれるコマンド）を使うです。 環境 RHEL6.2（EC2上に立ててる。Vagrantで立ててますが、その手順はまた別記事で） やり方 downloadonlyをyumで導入 デフォだとそもそもこれが入ってないので入れる。 # yum -y install yum-plugin-downloadonly 実際ダウンロードしてみる # yum install -
DockerとS3を用いた、yum / apt リポジトリ作成・運用の継続的インテグレーション - ゆううきブログ
Docker を用いた rpm / deb パッケージ作成の継続的インテグレーション - ゆううきブログ の続き。 前回は、rpm / deb パッケージを作るために、CentOS、Debianなど各種ディストリビューションを揃える手間をかけずに、Docker コンテナ上でパッケージングして、ついでに Jenkins で CI するみたいなことを書いた。 今回は、作成したパッケージを yum / apt リポジトリに登録して yum / apt コマンドでパッケージインストール/アップデートできるようになるまで継続的インテグレーションするという話。 問題点 yum / apt リポジトリ用の専用ホストを立てて、そこで apache とかで静的ファイルをホストするのはめんどくさい。 特に、mackerel-agent みたいなユーザにインストールしてもらうパッケージの場合、リポジトリを公開し
Docker を用いた rpm / deb パッケージ作成の継続的インテグレーション - ゆううきブログ
サーバ管理ツールのエージェント みたいなソフトウェアをインストールしやすくするために、rpm / deb パッケージを作りたい。 しかし、rpm / deb パッケージ化するためには、それぞれ CentOS(RedHat)、Debian(Ubuntu) 環境でパッケージ化することになる。 社内ではこれまでパッケージ化の専用ホストがいて、そこで spec ファイルや init スクリプトを置いて rpmbuild コマンドとか debuild コマンドを叩いてパッケージを作成していた。 さらに、アプリケーションエンジニアからインフラエンジニアに依頼するという形をとっていた。 この方法の問題点として、以下の3つがある。 spec ファイルや init スクリプトなどをプロジェクトの Git リポジトリで管理しづらい。つまり、レビューとかがやりにくい。 リリースフローを自動化しづらい。具体的には
自家製 td-agent のrpmをつくる - たごもりすメモ
自社サービスの運営のために fluentd を使っているとrpmでインストールできる td-agent が大変便利だ。 便利だが、自社内で使うんだから、もう最初から自社用の設定とかその設定に必要なプラグインとか入っててほしい。そんで yum install td-agent をサーバ上で実行したら設定とかいじらないでいいようにしたい。みんなラクをしたいでしょ！？ もちろん td-agent のリポジトリをforkしてあれこれ手を入れればできるが、そうするとその後のメンテナンスが面倒だ。リポジトリ自体のアップデートはTreasure Dataの人に頑張っていただいて、我々は spec をいじる程度に収めておきたい。みんなラクをしたいよねー。 した いろいろと td-agent のビルドスクリプトに手を入れる必要はあったが、もうその修正は当たっているのでみなさんは以下の手順を実行するだけでよろ
How to manage RPM packages with Git - Gosuke Miyashita
Now I manage RPM packages like this repo. I put source and binary packages in this repo.But this way has these problems. Binary packages' size is too big.It takes long time to git clone, push, pull and so on. I cannot see the history of each file in the packages. It's not very meaningful to use Git. I'd like to change like this. Put the requisite minumum files to see the hisotory of each file. Not
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
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 から取得してくれる） なので
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://qiita.com/la_luna_azul/items/b5cc0e33e18c7e2c5b02
GitHub - mizzy/how-to-manage-rpm-packages-with-git
silas/rpms - GitHub