CentOS Part 50【RHEL Clone】
■ このスレッドは過去ログ倉庫に格納されています
CentOS は Red Hat Enterprise Linux (RHEL) から同社の商標を削除して再コンパイルした RHEL Clone です。
Red Hat と無関係でもないコミュニティが無償配布してしますが Red Hat のブランドとサポートはありません。
* Fedora Core 6≒RHEL 5≒CentOS 5
* Fedora 13≒RHEL 6≒CentOS 6
* Fedora 19≒RHEL 7≒CentOS 7
です。
FCやRHEL 用のノウハウ、野良 RPM、レポジトリ云々は CentOS でもほぼ通用します。
前スレ
CentOS Part 49【RHEL Clone】
http://mao.5ch.net/test/read.cgi/linux/1531728260/
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 Scientific Linux、開発終了へ。今後はCent OSへ移行 2019年4月23日14:45 末岡洋子
https://mag.osdn.jp/19/04/23/144500
フェルミ国立加速器研究所のScientific Linuxプロジェクトは4月22日、メーリングリスト
にて次期版となる「Scientific Linux 8」の開発は行わないことを発表した。フェルミ
研究所は今後、学術向けコンピューティング環境として「CentOS 8」の実装を進めるという。
Scientific Linuxは、「Red Hat Enterprise Linux(RHEL)」互換のオープンソース
ディストリビューション。RHELをベースに商標に関わるものを削除た上で学術研究用途で
用いるパッケージを加えているのが特徴。フェルミ国立加速器研究所が欧州原子核研究機構
(CERN)と協力して開発してきたもので、自らが学術や研究用途で使うためのLinuxディス
トリビューションとして開発をスタートしたという経緯がある。
Scientific Linux開発中止の原因として、ほかの研究機関とのコラボレーションにあたって
土台のコンピューティングプラットフォームを連携させるため、としている。フェルミ
研究所は2018年9月、CERNとともに地下深部ニュートリノ実験(DUNE)と協力することを
発表しているが、これら国際研究機関との協力の一部として、「土台のコンピューティング
プラットフォームをこれらのラボや研究機関と統一させる」という。そこで、Scientific
Linux 8を開発するのではなく「CentOS 8」を実装することにしたという。
なお、RHEL 6ベースの「Scientific Linux 6(SL 6)」とRHEL 7ベースの「Scientific
Linux 7(SL 7)」については、ライフサイクル通りにサポートを継続するとしている。6系では
2018年7月に公開されたSL 6.10が、7系では2018年12月に公開されたSL 7.6が最新版となる。 >>5
ついに終わったか
大きいディストリ以外、安心出来ないな そんなに困ること?
クローンなんだし移行は簡単っしょ 他のマイナーなクローンだとプリンストン大とかのSpringdale Linuxはまだ生きてるか
GoOSeとかSerentosとかAscendosは死んだかな どうせメジャーバージョンアップ時は再インストールなんだしサポートされている間は仕えば良いじゃん Big Blue Linuxになったらどうしようも無いわけでさ 続けるのならDebianベースへ、やめるならCentOSへ、というのはSLの規定路線 >>15
と、思ったら追加があるみたいね
kernelアップされてるんで再起動しないとな CentOS7.4のDVDでインストールしたんですが、一気に7.6にバージョンアップする
と起動時のコンソール画面とX-Windowの解像度がVGAの640x480程度の解像度
になってしまいました。
このとき、いろいろググってみたら、/etc/X11/xorg.confの設定を変更する必要が
あることが出てきますが、そのファイルは存在していませんでした。
そのため再度インストールをやり直して、バージョンアップはしていないのですが、
すでに各種アプリも稼働しているので、このあと一気にバージョンアップして解像度
を保つには、どうしたら良いのでしょうか?
現時点で、アプリケーション>システムツール>設定>Displaysで解像度を選ぶと
1280x1024、800x600、640x480のうち、1280x1024が選択されている状態で、モニ
ターが22インチなので、1920x1080くらいにしたいと考えています。 >>19
>18です。Resありがとうございます。
グラフィックコントローラーはDELL PowerEdgr SC430のオンボードで、ネットで
検索すると当時のカタログにXGI XG20グラフィックスコントローラとあります。
かなり古いマシンですが、現役で使っています。 >>20
多分、インストール時はOpenManageDVDだかのインストール支援ユーティリティを使うことで
カーネルに対応したドライバが自動的に導入されていた、ということなのではないか
デルがRHEL7u6のビデオドライバを個別にリリースしてるんではないかな
それを入れないとならないのかもな
ここでRHEL7u4用のドライバしか提供されてない、なんてことだと、CentOS7.6は諦めるしかない SC430っていうとDellではRHEL4までのサポートかな
SC系はOMSA非サポートだった気もするが SC430なつかしい。10年以上前にDELLの在庫処分みたいなので買った。あのマシンは確か16レーンが無いか刺せないかなんかで、4か8レーンのソケットを熱で溶かして無理矢理16レーン用のビデオカードを刺してた。 >>20
7.4だと、vesaドライバが選択されていたのではないか
だからvesaドライバの設定に基づき、1280x1024までが選択肢に出ていた…と
それが7.6だと、vgaドライバを利用してしまうのでVGAで表示されている…と予感
まず、Xが上がってない状態で「Xorg -configure」とやると、xorg.confが作成されるので
/tmpだかで作成してみてほしい
で、「Section "Device"」とあるセクション内に「Driver」という欄があると思うのだが
そこが「Driver "vga"」となっていたりしないかな
そこを「Driver "vesa"」に書き換えると、とりあえずvesaドライバを利用させられるようになる
修正したファイルを/etc/X11/xorg.confとして置いてXを起動するとどうなるだろうか
「映らない」「エラー吐いて落ちる」だと、vesaドライバがそのXG20に対応しなくなっているので
残念だがCentOS7.4で使うしかない
PCI-ExpressスロットにGeForce 210あたりを取り付ける、というのはどうか SC430懐かしいな
ソアラからSCに変わった時100万円くらいアップしたけど欲しくて堪らなかった
どうしても我慢出来なくなってSC新車で買ったけどそれから1年してディスコン・・
一昨年くらいに後継のLC出たけど当時みたいに金持ってないから欲しくても我慢してる >>24
詳しい説明ありがとうございます。
実物は職場にあるため、連休明けに確認してみます。
因みに、7.4をインストールした時点で、これらドライバーやモニターの設定はどのディレクトリのどのファイルにあるのでしょうか。
少しは探ってみたのですが判らずじまいで、アップデート前の状態を一度確認出来たら、対応も楽なのではないかなと思います。 >>28
lspci -vの結果をみていくと、VGAだのVideoだのという名前のデバイスが表示されているはず
その中の「Kernel driver in use:」に続いて記載されているのが、いまそのデバイスのために
使っているドライバの名称・ファイル名
ドライバーは、カーネルのバージョン別に配置されている
cd /lib/modules/`uname -r`
find ./ | grep ドライバー名
とするとドライバの実体ファイルの表示場所が分かる
モニターの設定はEDIDで拾ってきたものをメモリに置いてあるものなので
ファイルとしては存在しない、かもしれない ハローワールド、レッドハットエンタープライズリナックス8
https://www.youtube.com/watch?v=voWBbUND3Fk
ITにはたくさんの世界がある。
オンプレミス、クラウドベース、そしてコンテナ。
でも、すべてのマシンで使えて、あらゆる環境を最適化し、複雑さを克服し、
そして、あなたに来たるべきイノベーションをもたらすのを助ける
ビルトインマネジメントと予測的分析機能を持ったOSはただひとつ。
その最新版がここに。
#上記はYouTubeのビデオ紹介文の和訳だが、原文はリズミカルでクールだね。 8になったらまたいろいろと変わってイライラさせられるんだろうか 8になって大きな変更はパッケージマネージャとpython周りかな さて、何日でCentOS 8がリリースされるか予想しようぜ 個人使いだからiptablesのほうがシンプルですき rhel8 beta でテストしたら CentOS 6 で使っている iptables のルールがそのまま適用できた。
まぁあまり複雑なことはしてないんだけれども。
注意点は save が無い(即保存される)くらいかね。 yum,dnfとちがってiptables,nftablesは書式が全く違うように見えるけど 7.0の時はRHELリリースから27日,6.0の時は242日
最近のマイナーリリースも25〜45日位で出てるし
1ヶ月くらい見積もってればよさそうかな その後2ヶ月は色々とバグが出てくるだろうから、手を着けるのは3ヶ月後、夏休みかな Redhat傘下になっても別にビルドプロセスが短縮されるわけじゃないんだな
今までどおり普通にリリース後のソースからか こっちに移動したほうが良いといわれたのでこちらで質問します
CentOS7.6の環境でansibleをインストールしようとしたところ
エラー: パッケージ: ansible-2.7.10-1.el7.noarch (epel)
要求: python-jinja2
このような出力が出てインストールが中断されてしまい、インストールできません
python-jinja2の関係だと思って、python-jinja2をインストールしてもまったく同じで何が原因か分らないです
ちなみにpythonのバージョンは2.7.5
epel-releaseはwgetでepel-release-7-11.noarch.rpmを取得しインストールしました
ちなみにansibleをインストールした際の出力とpython-jinja2のインストール確認コマンドは以下になります
[root@localhost pack]# yum install --enablerepo=epel ansible
読み込んだプラグイン:fastestmirror, langpacks
Loading mirror speeds from cached hostfile
* c7-media:
* epel: ftp.riken.jp
依存性の解決をしています
--> トランザクションの確認を実行しています。
---> パッケージ ansible.noarch 0:2.7.10-1.el7 を インストール
--> 依存性の処理をしています: python-crypto のパッケージ: ansible-2.7.10-1.el7.noarch
--> 依存性の処理をしています: python-httplib2 のパッケージ: ansible-2.7.10-1.el7.noarch
--> 依存性の処理をしています: python-jinja2 のパッケージ: ansible-2.7.10-1.el7.noarch
--> 依存性の処理をしています: python-keyczar のパッケージ: ansible-2.7.10-1.el7.noarch
--> 依存性の処理をしています: python-paramiko のパッケージ: ansible-2.7.10-1.el7.noarch
--> 依存性の処理をしています: python2-jmespath のパッケージ: ansible-2.7.10-1.el7.noarch
--> 依存性の処理をしています: sshpass のパッケージ: ansible-2.7.10-1.el7.noarch 続き
--> トランザクションの確認を実行しています。
---> パッケージ ansible.noarch 0:2.7.10-1.el7 を インストール
--> 依存性の処理をしています: python-jinja2 のパッケージ: ansible-2.7.10-1.el7.noarch
---> パッケージ python-httplib2.noarch 0:0.9.2-0.1.el7 を インストール
---> パッケージ python-keyczar.noarch 0:0.71c-2.el7 を インストール
--> 依存性の処理をしています: python-pyasn1 のパッケージ: python-keyczar-0.71c-2.el7.noarch
---> パッケージ python-paramiko.noarch 0:2.1.1-5.el7 を インストール
--> 依存性の処理をしています: python-cryptography のパッケージ: python-paramiko-2.1.1-5.el7.noarch
---> パッケージ python2-crypto.x86_64 0:2.6.1-16.el7 を インストール
--> 依存性の処理をしています: libtomcrypt.so.0()(64bit) のパッケージ: python2-crypto-2.6.1-16.el7.x86_64
---> パッケージ python2-jmespath.noarch 0:0.9.0-1.el7 を インストール
---> パッケージ sshpass.x86_64 0:1.06-1.el7 を インストール
--> トランザクションの確認を実行しています。
---> パッケージ ansible.noarch 0:2.7.10-1.el7 を インストール
--> 依存性の処理をしています: python-jinja2 のパッケージ: ansible-2.7.10-1.el7.noarch
---> パッケージ libtomcrypt.x86_64 0:1.17-25.el7 を インストール
--> 依存性の処理をしています: libtommath >= 0.42.0 のパッケージ: libtomcrypt-1.17-25.el7.x86_64
--> 依存性の処理をしています: libtommath.so.0()(64bit) のパッケージ: libtomcrypt-1.17-25.el7.x86_64
---> パッケージ python2-cryptography.x86_64 0:1.7.2-2.el7 を インストール 続き
---> パッケージ python-enum34.noarch 0:1.0.4-1.el7 を インストール
---> パッケージ python2-crypto.x86_64 0:2.6.1-16.el7 を インストール
--> 依存性の処理をしています: libtomcrypt.so.0()(64bit) のパッケージ: python2-crypto-2.6.1-16.el7.x86_64
---> パッケージ python2-jmespath.noarch 0:0.9.0-1.el7 を インストール
---> パッケージ sshpass.x86_64 0:1.06-1.el7 を インストール
--> トランザクションの確認を実行しています。
---> パッケージ ansible.noarch 0:2.7.10-1.el7 を インストール
--> 依存性の処理をしています: python-jinja2 のパッケージ: ansible-2.7.10-1.el7.noarch
---> パッケージ libtomcrypt.x86_64 0:1.17-25.el7 を インストール
--> 依存性の処理をしています: libtommath >= 0.42.0 のパッケージ: libtomcrypt-1.17-25.el7.x86_64
--> 依存性の処理をしています: libtommath.so.0()(64bit) のパッケージ: libtomcrypt-1.17-25.el7.x86_64
---> パッケージ python2-cryptography.x86_64 0:1.7.2-2.el7 を インストール
--> 依存性の処理をしています: python-idna >= 2.0 のパッケージ: python2-cryptography-1.7.2-2.el7.x86_64
--> 依存性の処理をしています: python-cffi >= 1.4.1 のパッケージ: python2-cryptography-1.7.2-2.el7.x86_64
--> 依存性の処理をしています: python-enum34 のパッケージ: python2-cryptography-1.7.2-2.el7.x86_64
---> パッケージ python2-pyasn1.noarch 0:0.1.9-7.el7 を インストール
--> トランザクションの確認を実行しています。 続き
---> パッケージ ansible.noarch 0:2.7.10-1.el7 を インストール
--> 依存性の処理をしています: python-jinja2 のパッケージ: ansible-2.7.10-1.el7.noarch
---> パッケージ libtommath.x86_64 0:0.42.0-5.el7 を インストール
---> パッケージ python-cffi.x86_64 0:1.6.0-5.el7 を インストール
--> 依存性の処理をしています: python-pycparser のパッケージ: python-cffi-1.6.0-5.el7.x86_64
---> パッケージ python-enum34.noarch 0:1.0.4-1.el7 を インストール
---> パッケージ python-idna.noarch 0:2.4-1.el7 を インストール
--> トランザクションの確認を実行しています。
---> パッケージ ansible.noarch 0:2.7.10-1.el7 を インストール
--> 依存性の処理をしています: python-jinja2 のパッケージ: ansible-2.7.10-1.el7.noarch
---> パッケージ python-pycparser.noarch 0:2.14-1.el7 を インストール
--> 依存性の処理をしています: python-pl y のパッケージ: python-pycparser-2.14-1.el7.noarch 続き
--> トランザクションの確認を実行しています。
---> パッケージ ansible.noarch 0:2.7.10-1.el7 を インストール
--> 依存性の処理をしています: python-jinja2 のパッケージ: ansible-2.7.10-1.el7.noarch
---> パッケージ python-ply.noarch 0:3.4-11.el7 を インストール
--> 依存性解決を終了しました。
エラー: パッケージ: ansible-2.7.10-1.el7.noarch (epel)
要求: python-jinja2
問題を回避するために --skip-broken を用いることができます。
これらを試行できます: rpm -Va --nofiles --nodigest
そしてpython-jinja2のインストール確認コマンドはコレになります
[root@localhost pack]# pip freeze
DEPRECATION: Python 2.7 will reach the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 won't be maintained after that date. A future version of pip will drop support for Python 2.7.
asn1crypto==0.24.0
(中略)
Jinja2==2.10.1
(中略)
yum-langpacks==0.4.2
yum-metadata-parser==1.1.4
何か間違っていたらすみません >>62
yumがrpmパッケージとしてpython-jninja2を要求してるのに、
pipのパッケージが入ってても仕方がない。 ■ このスレッドは過去ログ倉庫に格納されています