CentOS Part 51【RHEL Clone】

CentOS は Red Hat Enterprise Linux (RHEL) から同社の商標を削除して再コンパイルした RHEL Clone です。
Red Hat と無関係でもないコミュニティが無償配布してしますが Red Hat のブランドとサポートはありません。
* Fedora 13≒RHEL 6≒CentOS 6
* Fedora 19≒RHEL 7≒CentOS 7
* Fedora 28≒RHEL 8≒CentOS 8
です。
FCやRHEL 用のノウハウ、野良 RPM、レポジトリ云々は CentOS でもほぼ通用します。

前スレ
CentOS Part 50【RHEL Clone】
http://mao.5ch.net/test/read.cgi/linux/1555069001/

CentOS (The Community ENTerprise Operating System)
http://www.centos.org/

CentOS 配布ミラーサーバ
http://www.centos.org/download/mirrors/

CentOS -- Wikipedia日本語版
http://ja.wikipedia.org/wiki/CentOS

● サードパーティのレポジトリなど

利用可能なレポジトリ一覧
https://wiki.centos.org/AdditionalResources/Repositories

EPEL (Extra Packages for Enterprise Linux)
http://fedoraproject.org/wiki/EPEL

RPM Fusion
https://rpmfusion.org/

Les RPM de Remi
http://rpms.famillecollet.com/

ELRepo
http://elrepo.org/tiki/tiki-index.php

●Red HatによるRHEL関連ドキュメント一覧
https://access.redhat.com/documentation/ja/red-hat-enterprise-linux/

長らく更新停止
RepoForge
https://wiki.centos.org/AdditionalResources/Repositories/RPMForge
http://repoforge.org

CentOS8リリースに伴う追加変更等あればフォロー願います

たて乙

1乙

SI責任押し付ける相手がいていいねw みたいな発言してるやつがいるが
プログラムばっかり書いてカネの流れに無頓着なのは如何なものかと思うぞ

実際ハード障害なんだけど証拠がない場合での予防交換対応(証拠はない
けど交換します)に応じる・応じないのハードルの高さは保守料含めた
金払いで決まる

予防交換できずに何週間も本番機が停止だの高頻度の再起動が続くだの
で長引くことを考えると保険としてサブスクリプションは高くない

ハード障害までRHに責任取らせるつもりなのか
これだから無職脳内SIは…

Linuxの問題点って、何か問題があった時に、それが仕様なのかバグなのかはっきりしないことでしょう。
これは間違いなくバグだ！と言い切ったところで、カーネル開発者が修正しなければ事実上の仕様として放置されてる状態なんだし。
その点、レッドハットはカーネル開発に人員を送り込んでいるので、意思決定に直接携わることができる。
これが、レッドハットが選択される理由になるんじゃないですかね。

RedHatは客から金取ってるんだから当たり前

>>8
RH に払う金の一部がハードベンダーに落ちて、その金で予防交換させてんだよ
底辺プログラマは文章も読めんのか？

>>9
ハードベンダーに落ちる金がBroadcomだのIntelだのに回ってファームウェアか
デバイスドライバを直してるんだよ
直してるのは RH じゃなくてチップメーカ

RHサブスクリプションをOEMで買ってる客とCentOS使ってる客/サイオスから
サブスクリプション買ってる客とではそれらのチップメーカにエスカレーション
できる・できないでサービスレベルが違う

ここは Windows を OEM で買うか、別商流で買うかでも同じ

>>11
アホですか？

>>11
>RH に払う金の一部がハードベンダーに落ちて、その金で予防交換させてんだよ

そういう文章になってないし、RHからハードベンダーに金が行くことはない
君の文章は明らかにおかしい

>>12
アホではあるが書いた金の流れは嘘じゃないよ

>>13
指摘すまんね
OEMの代金として払った金額の一部がハードベンダーに落ちるが正しかったわ

OEMで購入した場合のハードベンダサポートの話と、RHサポートの話が混ざっているみたいだね
以下でいいんじゃないだろうか

・RHのサポートでできること
ソフト面の異常有無確認、ワークアラウンドの提示、パッチの公開

・ハードベンダのサポートでできること
ハード面の異常有無確認、ワークアラウンドの提示、機器交換対応

・ハードベンダからOEMでRHELを購入するとできること
上記2つを一元受付、内部ナレッジで解決しないRHELの問題はRHへエスカレーション

というか、CentOSの話題とはだいぶ離れてきているので、
それぞれのサポートの話題はRHELと各メーカのサーバ機器のスレでやった方が良いのでは

誰かに金を沢山払ってて、それで全てやってもらってるんだろうな。そういうやり方もあるってのはその通りでしょう。
でも、仕組みは正確に理解してないか、正確で分かり易い文章にはできなかったってことよね。

金払ってやってもらうって考えじゃダメって事を延々説明してるんだがな

ネットワーク経路上のスイッチとの相性が悪くてデバイスドライバとファーム
ウェア両方直さないといけない症状になった場合、自分で直せるのか？
RHEL だと予防交換してくれるはずが CentOS だとしてくれないパターンも
ありうるぞ

契約書だの要求仕様書にそういうのは対応できない／しなくてよい事を書くか
タダだからしょうがないよねって客が言ってくれることを握って初めて本番系に
CentOS 入れれるんだよ

CentOS 入れれるのは客や現場に甘えさせてもらってるって意識がないと
別の客に持って行った時に痛い目合うぞ

まずは部屋から出よう
世の中の常識を学ぼう
それから就職して現実を知ろう

金はないけどRH使いたいって貧乏会社ってだけだよ

>>17
「RHEL だと予防交換してくれるはず」という書き方だと、
RHがハード保守してくれるようにも受け取れてまたつまらない論争になるから、文章に主語を入れたほうがいいよ

・ハードベンダは、同社のハードとRHELの組み合わせを動作保証している
・CentOSは動作保証していないので、ソフトウェア異常無し、ハードウェア異常有りを自力で切り分けないと保守対応してもらえない
・故に、RHELもハードベンダからOEMで一括購入すべき

てことを言いたいんだよね？

>>20
> ・CentOSは動作保証していないので、ソフトウェア異常無し、ハードウェア異常有りを自力で切り分けないと保守対応してもらえない
大雑把にはその通り
実際は CentOS 動作保証してても一部エスカレーションしてくれないパターンがある

> ・故に、RHELもハードベンダからOEMで一括購入すべき
yes
購入する理由はこれだけではないですが
あと、スレチと言われちゃうのでスレ的には RHEL 購入せずに済ます場合のビジネス要件は何か、だな

>>17
やっぱ分かってないだろ
OEM経由で買ったんならCentOSだろうがRHだろうが、ハードの障害は対応するだろ（値段次第だが）

>>22
ベンダのハード保守は、OEMでOSを同時購入したかどうかに関係なく、
リモート管理ボードの診断ツールやステータスランプ状態に異常が検出されれば対応してもらえるよ。
ただし、Pingが飛ばない、ディスクに書き込みできないレベルの情報では動いてもらえないので、必ず上記の切り分けが必要。

https://h50146.www5.hpe.com/services/cs/availability/hw/onsite.html
https://japancatalog.dell.com/c/ent-support-guide/

17の主張の一つは、上記ハード異常が検出されない場合のソフト保守に差がある点じゃないかな。
RHELは一旦置いておいて、CentOSの場合とハードベンダ動作保証OSの場合で考えると以下の対応差が出る。

・CentOS
全てを自力で調べて設定変更なりソースの修正を行う

・ハードと別購入の動作保証OS
OSベンダのサポートに原因と対応方法の調査を依頼する
OS自体の対応はしてもらえるが、ハードベンダ独自のドライバ起因の問題は対応してもらえない
再度ハードベンダのサポートに、OSベンダの見解を伝えドライバ修正の対応を依頼する(対応はベストエフォート)

・ハードと同時購入の動作保証OS
ハードベンダのサポートに、原因と対応方法の調査を一元的に依頼する

>>23
フォローありがとうございます
おっしゃる通りでBMCで検出できるエラーや交換すりゃ直るだろう程度以外の、
厄介な障害の場合が議論の対象です

>>22
OEM経由ではCentOS買えないですね
それはさておき値段次第ってのは合ってます
が、千台ぐらいサーバ入れてるような上得意だけの裏メニュー

くっさｗｗｗ

レンタルサーバーにOS入れたいんですが今ならCentOS8入れたほうがいいですか？
CentOS7ってもう古いですよね？yumもPython2系ですし

>>26
検証リストを作成し
2つ環境を作って自分のニーズにどちらが合うか検証

>>27
私は基本的にOSは新しい方が良いと思っているんですが、そういうケースではない場合もあるんでしょうか
適材適所で要件を満たしていれば一世代前のOSでも良しとするということがあるんですか？

使いたいソフトウェアが新しいOSに対応していないとかある
問題ないなら新しい方でいいよ

>>29
なるほど・・・
新しいOS使う場合は>>27さんが言うように問題ないか検証する必要があるみたいですね
どうもありがとうございましたm(_ _)m

だれかamdのcpuの温度とクロックを見る方法を教えて下さい
sensorsだとhardware tempとか言うやつが出るだけで温度も高めです
常時５０℃とか

https://github.com/openhardwaremonitor/openhardwaremonitor/pull/970

ビジネス要件とかそういうのも本来はスレチ。ここはCentOSを売ってる人の為というよりはCentOSをいじってる人の為にある。

>>33
あふぉか

責任をRHに丸投げするスレです

xfsのファイルシステムがクラッシュした。
2日連続で2台のサーバーがこのバグでクラッシュした。
ここに対応策が書いてあるんだけど、内容が結構すごい
> CentOS 7.0, 7.1, 7.2の場合は7.3をリインストールする必要があります。
> アップデートではこのバグは修正されません。
https://help.onapp.com/hc/en-us/articles/115001373554-XFS-File-System-Crashes-on-CentOS-7

>>36
怖すぎだろ？

何となく今までext4選んでたのは正解か

xfsをCentOS5で使っている俺にはスキは無かった

幸い？ウチのは問題でてないな…
reinstall というより format が必要なんかね。

>>36
公式では情報ないの？

>>28
馬鹿の典型例

centOS8 stream版をノートに入れてみた。
普通にデスクトップ用戸で使ってる。
問題なく使えてる。DVDも観られるし。
家のLinux PC、全部これで行ってみようかな。

>>43
７と違う？

firefoxは最新版が入るみたい。
デスクトップ用戸だと、特に違いも不便も感じない。

用途。だった。

>>36
確かにCentOS7.2以前にはXFSがクラッシュするバグがあるみたいだけど，
そのURLに書かれてるのは，
onappという会社が提供するクラウド環境において提供される
CentOS7.2を元にしたクラウド実行イメージでは，
アップデートをしても本家の7.3で修正されたカーネルのパッチが
提供されることはないので，7.3を元にした実行イメージを
再インストールして下さいって話でしかないのでは？

>>47
他では全然聞かないもんな

>>42
なぜ？

>>47
CP serverってなんじゃろ？と思ってたがそういうことか。
しかし、リンク先を読まずに>>36を解釈してしまう人の多いこと。デマ、都市伝説、思い込みはこうやって作られるを見た気がする。

>>47
つまりは、普通に使ってる分には
大丈夫でしたか

XFSのファイルシステムがクラッシュするという件についてなんだけど、
恐らくこのバグにヒットしたんだと思う。
https://bugzilla.redhat.com/show_bug.cgi?id=1315895
このカーネルエラーについては検索するとかなりヒットする。
7.3でFIXになってたので環境は7.3以前のものかと思い込んでたが、確認したら7.5になってた。
恐らく、このバグはまだ潜在的に残ってるんではないかと思う。
障害が起きた状況は、テキストマインイング用の前処理の過程で600万件位の
テキストファイルをキャッシュ用に作ったディスクに書き出し、読み込むというもの。
プログラムは処理時間短縮
（普通に流すと3日くらいかかるものをマルチスレッド化して6時間で終わらせてる）
のためCPUとディスクは限界まで動いてると思う（サーバーはDELL R710/24CPU）。
で、このプログラムを動かすほぼ確実に上のバグのカーネルエラーが発生することが
わかったので、結果的に中間処理用のディスクはEXT4で切り直した。
で今、１回目の処理を流してるところ。
書き出してるファイルは全部テキストファイルで複雑な処理はしてないんだけど。

inodeテーブルの枯渇とかではなく？

そもそも7.2標準のカーネルはfanotifyのバグあるで
updateしや

そもそもそんな中途半端なバージョン使ってる人いるのかね

8.1ﾏﾀﾞｰ?

>>56
Distribution Release: Oracle Linux 8.1
https://distrowatch.com/?newsid=10739

>>57
オラクルってまだあったの？
しかも、早いとか謎

Solarisがほぼ死んでるからoracleはLinuxに力入れてる

自分で殺したくせになあ

ZFSくらい自前で実装しろよと

早々に CentoOS6→8 に切り替えちゃったのがあるんだけど早まったかなぁ。
update が全然落ちてこないうちに RHEL8.1 が出たのね。

CentOSに限らないがメジャーアップデートしたばかりのソフトウェアをメインに導入するのは避けたほうがいいよ

>>63
だな

検証用の環境を作って様子を見ながら.1や.2がくるのを待つのが普通だと思ってた

窓なら、SP1が出た後、次のロールアップが出てから考える位でしょw
飛び付いて良いのはテスト環境のみかと・・・。

RHEL 8 からは半年ごとにリリースになってる
7 は不定ではあるけど大体9ヶ月ごとだったので短くなってるね
その代わり延長サポートなしのリリースが含まれるようになった

https://access.redhat.com/support/policy/updates/errata#Maintenance_Support_2_Phase
によると 8.0, 8.3, 8.5, 8.7 は延長サポートなし
CentOS や RHEL だけど EUS は買わないという人だと恩恵ないので関係ないっちゃ関係ないけど
商用アプリベンダーサイドがそのリリースはサポートしないという可能性はゼロじゃない
だから9ヶ月毎が6ヶ月毎になったんじゃなくて12ヶ月ごとになったと考えてる

過去の経験上 x.0 がでて２年ぐらいが大体主力になるので 8.4 が出た段階で使いこなせるように
検証すればいいんじゃないかな

>>67
その頃には９が出てるかもｗ

そして>>63へ戻るw

ここ数週間で、Cray がスパコンに富士通製のARM使う事発表したり
理研が RISC-V 実装のスパコン発表したりで、CPU業界が一気に動き
始めてるからシャレになってないんだよなあ

富士通はすぱあくやめてまうん？

続けると言ってはいるが既存SPARCユーザへのリップサービスでしょ
他社(Cray)に提供する以上自分たちのペースでまったり開発は出来なくなるわけで
SPARCに余力を割くことなんてできやしないよ

遅かれ早かれやめるんだろうな

1年ぐらいに停止していたcentos7(外部サービス無し)って
久しぶりに起動してupdateしたらミラーリスト全部7.6系が取れずに失敗するのね

yum updateでリリース番号が古い方を取ろうとしてエラーになってしまう・・・
どこを参照しているんだろう。

# cat /etc/redhat-release
CentOS Linux release 7.7.1908 (Core)

# cat /etc/centos-release
CentOS Linux release 7.7.1908 (Core)

# yum update
読み込んだプラグイン:fastestmirror
http://ftp-srv2.kddilabs.jp/Linux/packages/CentOS/7.6.1810/os/x86_64/repodata/repomd.xml: [Errno 14] HTTP Error 404 - Not Found
他のミラーを試します。

wget 'http://mirrorlist.centos.org/?release=7&;arch=x86_64&repo=os&infra='
実行したが、
http://ftp-srv2.kddilabs.jp/Linux/packages/CentOS/7.7.1908/os/x86_64/
などすべて 7.7.1908 で返してきたよ

yum がフィードするのは 7 までで .7.1908 はミラーリスト返すウェブサーバが
付与してるんでWebのキャッシュってことかな

/etc/yum/vars/releasever とかにバージョン固定の値を書いてないかな？

>>76のキャッシュの言葉で
結論から書くと、yum clean all使ったら無事いけたわ、サンクス

# wget 'http://mirrorlist.centos.org/?release=7&;arch=x86_64&repo=os&infra='
`index.html?release=7&arch=x86_64&repo=os&infra=.1' に保存中
「.1」って何だろう、というか 7.7.1908とかいう表記に変わったのにびっくり。

>>77
contentdir infraはあるけど、releaseverは無かったわ
固定値いれられるのね、勉強になりました。

>>67
意味不明

8.0 → 8.1
8.1 → 8.2
8.2 → 8.3
8.3 → 8.4
:
8.9→ 8.10

のupdateは yum (dnf) で簡単にできるけど。

そのバージョンで開発してサービス稼動開始したもの、納品したものなんかをおいそれとバージョンアップできないからとか色々事情はあるだろうし。

>>80
だな、
未だに６だわ

CentOSで商用サービスリリースしちゃったの…？

自社サービスなら、普通じゃね？RHに金払う理由もないし

>>82
かなり普通だと思うけど違うの?

>>80
メジャーならばともかく、マイナーバージョンアップで動作不良になること、
めったにないよ。　よほど、タコなプログラミングでもしてない限りは。

>>85
その滅多に無い事が、往々にしてあるから怖いんだよ。

>>79
開発やテストを軽視しているのか必要ない利用環境なのかはわからんが、
7.2 上で作った自作のソフト・スクリプトが 7.3 で動かないとか性能出ないとか、
やり方/画面変わったから運用手順書作り直したりとかあるんだわ

8.0 から始めるのは流石にバカらしいからどこから参戦するかって考えないのか？

>>87
>>79は、その0.1の差は更新のみと考えてるんだろうな。
何も知らないんだろうから、放っておくに限るよw

アホはスルーせよｗ

CentOSは普通に商用鯖に使われてるしなんならRHELよりシェア高いでしょ

>>87
性能出ない理由はなんだったの？
アスペ向けの手順書だったら.1の差でも修正が必要なのは分かるんだが

>>91
性能出ない、はあくまでも例で 7.3 がってわけじゃないよ
大体ハードでファームウェアとの相性なのかなんなのか正しく認識できない
みたいなのは偶にある

手順書はそうやって油断してると本番でトラブったときに出力が違うことを
理由に何日も足止めとかあるからバカにしないほうがいいぞ

>>92
つまりありもしないことをでっち上げたってこと？
それでよくもまあテストを軽視してるとか酷いことを言えるもんだなあ

7以降，RHELは収録ソフトウェアの
リベース(メジャーバージョンアップ)を
積極的にやるようになったから
.1の違いでも何が起こるか分からないよね。

6までは，収録ソフトのバージョンは変えずに
セキュリティーアップデートの部分だけを
バックポートするのが多かったけど
大変だったんだろうな

確率とそれぞれの事情の問題なので、好きにしろでFA。

不測の事態が発生する可能性　←わかる
性能問題が発生した　←嘘

嘘はよくないよ