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 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のパッケージが入ってても仕方がない。 >>63
長すぎて入らなかったので申し訳ありません
>>64
やってみます
このような事で質問してしまい申し訳ありません ansibleはextrasにもepelにもあるようだな。うちではどちらを入れようとしても特に問題なく依存解決される。入れようとするのは以下。
python-jinja2 noarch 2.7.2-3.el7_6 updates 518 k
pipで python2-jinja2 を入れてるがゆえにrpmのが入れれないじゃないか。 >>62
あっちのスレで指摘したjinja2のバージョン違いの問題は調べたのか？ pipでインストールしたモノが上書きされないように
yum.confかどこかに
python-jinja2をexcludeするルールでも書き込んだんじゃないの？ EPELにあがっているAnsibleってel7用になってはいるけど
CentOS7.6にはまだ導入できないとか、そんなんのでないの Chef のレシピ集でも探せば？
Chef 社はじめ、色んな会社が出してるだろ インストールソースの選択でエラーになります
誰か解決法はご存じですか？
お願いします ftp.riken.jp/Linux/centos/os/x86_64/あたりだっけｘ >>72
すまん。
ftp.riken.jp/Linux/centos/7/os/x86_64だったな >>72
すみません、そのurlから落としたと思います >>76
すみません、自己解決しました
ありがとうございます。 >>78
すみませんけど自己解決したのでこの話題は無しで。 同じところで躓いた人がそれで助かるかも知れないからな 5ch のルールを守らない人は、5chを利用してはいけない！
自己解決した場合も、どうやって解決したのか、書かないといけない！
それがこの板のルール！ 質問の仕方も悪けりゃ、勝手に自己解決で書き逃げ。どうせろくでもない理由なんだろう。 あの程度の奴が躓いた理由に興味がないし
それの解決策載せられても参考になりそうにないよ >>89が興味あるかどうか>>89にとって参考になるかどうかはどうでもいいことだな 随分反応あるね。よくある事。この流れが嫌な人は最初から見ない事。 そんなことよりきいてくれよオマイラ。
そうじゃなくて、スイマセン、質問です！
web/DNS目的でcentosの鯖をグローバルに出そうと思ってるんですが、経験済みの人視点でおすすめのパッケージとかありますか？
centosにnic２つ繋いで、グローバルとプライベートネットワークそれぞれ接続し、
セント鯖まではhttps強制、プライベートにHTTPでホストアドレスをバーチャルホストで流し、セント鯖でsquidを使ってキャッシュしつつnginxで外に流してhttp/2で飛ばせればいいなとか考えてます。
DNSはdnsmasqだったかな？
あれを使おうと思います。
御指摘等頂ければ幸いです。宜しくお願いします。 おすすめのパッケージってどういう意味だろ。Cent用を使えばいいんじゃないだろうか。 パッケージってそりゃ、DNS は bind 使うのか dnsmasq 使うのか、リバースプロキシは httpd(apache)
使うのか squid 使うのか、web は httpd 使うのか nginx 使うのかって意味でしょ。 vpsじゃないのにわざわざnicにグローバル割り当てるのか、
玄人さんやな。
近辺のipアドレスが16ビットマスクで
spamhausに登録されるのも時間の問題やな。 本人、squidとnginx使いたいみたいだからそれでいいと思う。 かぶってる人間のイメージが悪いんだって
帽子だけってのも慣れないが。 全てのcentos7サーバからyumのxmlがらみのたくさんエラー来てるけど、放置してok？
/etc/cron.hourly/0yum-hourly.cron:
Updateinfo file is not valid XML: <open file '/var/cache/yum/x86_64/7/epel/92f2e15cad66d79ea1ad327e2af7af89d98e4d153d7a3e27ff41946f476af5b4-updateinfo.xml.zck', mode 'rt' at 0x******* >>28です。かなり遅くなりましたがやってみました。
>>24で教えてもらったXorg -configureで作成されたxorg.conf.newを編集し、/etc/X11にxorg.confで保存しましたが、再起動するとコンソールにログが表示されたままで止まってしまいます。
編集したところは、Section "monitor"のVenderName、ModelNmae、HorizSinc、VertRefreshとSection screenのSubSection "Display"のSubSection "Display"のModesです。
以前はModelineの設定もあったように思いますが、書き方自体も判りません・CentOS7では不要なのでしょうか？
編集したヶ所を以下に示します。これ以外はオリジナルのままです。何がダメなのでしょうか。
-------------------------------------------------------------------------------
Section "Monitor"
Identifier "Monitor0"
VendorName "MITSUBISHI ELECTRIC"
ModelName "RDT222WM"
HorizSync 31.2 - 82.3
VertRefresh 56.0 - 76.0
EndSection
Section "Screen"
Identifier "Screen0"
Device "Card0"
Monitor "Monitor0"
SubSection "Display"
Viewport 0 0
Depth 24
Modes "1920x1080" "1680x1050" "1280x1024" "1280x960" "1152x864" "1024x768" "800x600" "640x480"
EndSubSection
EndSection
------------------------------------------------------------------------------- >>111
yum clean allしても解決せず。
そりゃ振ってくるxmlが壊れているなら仕方無いか。
すべてepelをdisableしていずれ戻すのは面倒なので1時間に20通ぐらいエラー来るのは受け入れるわ。 CentOS v6.10なんですが、PEA無しCPUが乗ってる古いPCにもインストール可能でしょうか？ >>114
RHEL6からもうPAEが必須なので、CentOS6ではインストーラもブートしなかった記憶 centos7のi386版（altarch）ってどうなん？ 英語で何と言うか調べたら Death star だった。
スカイウォーカーさんちか。 スカウォーカーさんが乗り込んでいくとこじゃないか？ 帝国はとても強い
皇帝はとても偉い
戦艦はとてもでかい
タイファイター速い
ダースベイダー黒い
ストゥームトルーパーは白い
ロイヤルガード赤い
デス・スター丸い 規模がでかいだけで結局は親子喧嘩の話はSF板でやってどうぞ デカ チンの上にイケメンテクニシャンすぎて
一度でもセク ロスすると
何度も何度もセク ロスをおねだりされて
全員に断るのマンドクセェ(;´･ω･)
これは罪か、それとも罰か。 なんでこう毎度 Windows Update の日に重ねてくるのか… MSのこの仕打ちでCERNのCentOS使用が更に加速するか？
ライセンス料が10倍に跳ね上がることを理由にCERNがMicrosoft製品からオープンソース
ソフトウェアへ移行 2019年06月13日 13時00分
https://gigazine.net/news/20190613-cern-microsoft-alternatives-project/
欧州原子核研究機構(CERN)ではこれまで20年にわたりMicrosoft製品を使い続けてきま
した。その理由の1つに、CERNが「学術機関」であることで、特別な条件で契約できて
いたというのがあるのですが、この方針をMicrosoftが転換。新たな契約はユーザー数に
基づいてライセンス料を支払うもので、CERNの負担額はこれまでの10倍に増加するという
ことで、Microsoft製品からオープンソースソフトウェアへの移行プロジェクトを進めて
います。(後略) >>133
今まで1割で済んでたってことは、CERNのライセンス数が半減してもMSには得か 記事にもあるけど、ここでいう契約の対象はスケジュールや Web 会議、Office 製品を含む
業務管理(Exchange/Skype for Biz./SharePoint/Outlook) であって OS ではないでしょ。
研究機関の場合、企業と違って同じハードに同じソフトを入れてPC配るなんてことはしなくて、
各研究者が好きなPC(つーかMac)を買うだろうし、サーバも計算用は Linux で、Windows
Server なんてほとんど入らないから OS 部分で MS 直契約 (ボリュームライセンスや
SA 契約) はしないんじゃないかな？ Windows Server結構使われてるぞ
あれはドザーにはいいものだ 混在環境の認証基盤だとしては、もうActiveDirectory一択でないかな どなたか、お教え願います。
以下はXorg.0.logの一部ですが、
[ 650.653] (II) LoadModule: "vesa"
[ 650.654] (II) Loading /usr/lib64/xorg/modules/drivers/vesa_drv.so
[ 650.654] (II) Module vesa: vendor="X.Org Foundation"
[ 650.654] compiled for 1.20.1, module version = 2.4.0
[ 650.654] Module class: X.Org Video Driver
[ 650.654] ABI class: X.Org Video Driver, version 24.0
[ 650.654] (II) VESA: driver for VESA chipsets: vesa
[ 650.654] (++) using VT number 1
(途中、省略)
[ 651.984] (II) VESA(0): Monitor0: Using hsync range of 31.20-82.30 kHz
[ 651.984] (II) VESA(0): Monitor0: Using vrefresh range of 56.00-76.00 Hz
[ 651.984] (II) VESA(0): Monitor0: Using maximum pixel clock of 165.00 MHz
[ 651.985] (II) VESA(0): Not using built-in mode "1600x1200" (width too large for virtual size)
[ 651.985] (II) VESA(0): Not using built-in mode "1024x768" (no mode of this name)
[ 651.985] (II) VESA(0): Not using built-in mode "800x600" (no mode of this name)
[ 651.985] (II) VESA(0): Virtual size is 1280x1024 (pitch 1280)
[ 651.985] (**) VESA(0): *Built-in mode "1280x1024"
[ 651.985] (**) VESA(0): Built-in mode "640x480"
[ 651.985] (**) VESA(0): Display dimensions: (470, 300) mm
[ 651.985] (**) VESA(0): DPI set to (69, 86)
[ 651.985] (**) VESA(0): Using "Shadow Framebuffer"
できれば1600x900で使いたいのですが、これはビルトインモードの以下でスクリーン解像度で限定されているということでしょうか。
1600x1200
1280x1024
1024x768
800x600
640x480 ■ このスレッドは過去ログ倉庫に格納されています
