:::: MENU ::::

CentOSのyum更新で衝突しまくり

CentOS 7.4で、久しぶりにyum更新したら、下記のように衝突が発生

….
—> パッケージ rdma-core.x86_64 0:15-6.el7 を アップデート
—> パッケージ tar.x86_64 2:1.26-32.el7 を 更新
—> パッケージ tar.x86_64 2:1.26-34.el7 を アップデート
–> 衝突を処理しています: initscripts-9.49.41-1.el7.x86_64 は redhat-release < 7.5-0.11 と衝突しています
–> 依存性解決を終了しました。
問題を回避するために –skip-broken を用いることができます。

–skip-brokenにすれば、衝突していないパッケージは更新され、衝突パッケージではexcludeを設定することで回避できるのですが、今回のは衝突が多すぎました。

ん? よく見ると、”7.5-0.11 と衝突しています”

7.5がリリースされ、更新が多いのかと思い、頭をよぎったのが・・・

yum.confの除外設定で、kernelを除外設定にしていた影響です。

exclude=kernel*

この除外設定を無効にしたのち、yum更新したところ、はい、無事に衝突が起こらずに、7.5へアップデートされたとさ。

自業自得でした。m(_ _)m

参考までにCentOS 7.4から7.5へのアップデート

https://www.cyberciti.biz/linux-news/rhel-7-5-released-how-to-upgrade-7-4-to-7-5/


ChromeのHSTS解消メモ

Google Chromeにて、httpを指定しているにも関わらず、httpsへ勝手にリダイレクトし、httpではアクセス出来ない事が多いので、メモです。

HSTSは、HTTP Strict Transport Securityの略で、httpの代わりにhttpsを用いて通信を行うセキュリティ機能です。

詳しくは、下記のブログをご覧いただければと思います。

 

解決方法

Google ChromeのURLアクセスバーに、

chrome://net-internals/#hsts

と入力し、下部にある「Delete domain security policies」で該当するドメイン名を入力し、deleteを押すだけです。

これでも、変化がないようであれば、Google Chromeを再起動、キャッシュの削除、クッキーの削除を行ってみましょう。


letsencrypt更新でEPELを要求

letsencryptの証明書が切れたので、再発行によるコマンドを叩いたら、下記のエラーで更新できず。

# ./letsencrypt-auto certonly --standalone -d <domain> --renew-by-default

To use Certbot, packages from the EPEL repository need to be installed

epelのパッケージは導入済みで、最新のパッケージがインストールされてますよ〜って止まる

これ、インストールの他に有効にしなさいと言うメッセージが抜けてるね

/etc/yum.repo.d/epel.repo
enable = 1   # 0から1へ変更

再度、再発行コマンドで無事通りました


etckeeperで/etcをgit管理

/etcをGit管理出来るetckeeperは以前か知っていたのだが、放置したままだったので、今更導入してみた。

インストール

Redhat系

# yum -y install etckeeper --enablerepo=epel

Debian系

# ap-get -y install etckeeper

設定

/etc/etckeeper/etckeeper.confの下記箇所を確認及び追記

VCS="git"
 PUSH_REMOTE="origin"

初期化

# cd /etc/
# etckeeper init

origin追加

# git remote add origin git_url

コミット

# etckeeper commit -m 'first commit'

bitbucketの利用

githubでもやることは同じ

  • bitbucketにログインし、リポジトリを作成
  • etckeeper側ホストでoriginの登録
    # git remote add origin git@bitbucket.org:user/repo
  • ssh鍵の登録
    etckeeper側ホストでrootにて、鍵がなければを作成する(パスは空で)

    # sh -c 'ssh-keygen ; less /root/.ssh/id_rsa.pub’

    表示されたssh鍵をbitbucket側に登録する

注意することは、作成したリポジトリの設定でSSH鍵を登録するのでなく、アカウント設定欄からSSH鍵を登録すること。
各リポジトリ設定でssh鍵を登録するとリードオンリーとなりアクセス拒否されてしまいます。

  

自動実行

etckeeperをインストールした時点で、/etc/cron.dailyにスクリプトが作成されるので、毎日自動で/etc内を更新してくれるようになっています。

一度、手動実行して、無事に登録出来るのか確認してみると良いでしょう。

# /etc/cron.daily/etckeeper

古いCentOSのリポジトリを復活させる

職場のサーバーで、未だにCentOS 5.11を使い続きているサーバーがあるのですが、CentOS 5系は昨年の3月でサポート終了となり、アップデートも行われません。

それは、承知なのですが、時に、足りなかったプログラム等をインストールしたい時が生じます。

しかし、yum更新はおろか、yumによるプログラムのインストールさえ行えません。

# yum install xxxxx

YumRepo Error: All mirror URLs are not using ftp, http[s] or file.
Eg. Invalid release/
removing mirrorlist with no valid mirrors: /var/cache/yum/base/mirrorlist.txt
Error: Cannot find a valid baseurl for repo: base

既にサポートが終了しており、ミラーリストにも存在していないようですが、幸いにもvault.centos.orgが引き継いでくれているようで、baseurlをここへ向けることで対処することが出来ます。

/etc/yum.repos.d/CentOS-Base.repoのバックアップをとり、下記に書き換えます。

[base]
 name=CentOS-$releasever - Base
 baseurl=http://vault.centos.org/5.11/os/$basearch/
 gpgcheck=1
 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5

[updates]
 name=CentOS-$releasever - Updates
 baseurl=http://vault.centos.org/5.11/updates/$basearch/
 gpgcheck=1
 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5

[extras]
 name=CentOS-$releasever - Extras
 baseurl=http://vault.centos.org/5.11/extras/$basearch/
 gpgcheck=1
 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5

これで、CentOS 5.xでもパッケージのインストールが可能となります。
Vaultのサポートがいつまで続くのかわからないし、セキュリティ的にも最新のOSへ移行したほうが賢明なのはわかっているのですがね・・


Mac版VirtualBoxのインストールが検証中のまま進まない問題

VirtualBoxは、1年に数回しか起動しないので、久しぶりに起動すると、アップデートを必ず促されるので、アップデートを行っていますが、毎回、Mac版VirtualBoxのインストーラーが検証中のまま進まないので、メモしておく。

https://forums.virtualbox.org/viewtopic.php?f=8&t=77122

sudo installer -package /Volumes/VirtualBox/VirtualBox.pkg -target /

なお、システム環境設定のセキュリティとプライバシー内の、ダウンロードしたアプリケーションの実行許可を「すべてのアプリケーションを許可」にしておく事も必要かもしれません。


Lets’s Encryptの証明書期限切れたので再作成

SSL証明書では、Lets’s Encryptの証明書を利用しているのですが、期限が3ヶ月なので、ちょっと油断していると証明書切れになります。

事前に、証明書を更新する通知も来るのですが、後回しにしていたら、期限が切れてしまいましたので、再作成しました。

再作成なので、certbot-auto renewすればいいんじゃね?
しかし、renewだけじゃ、証明書が期限切れのままでダメでした。
なので、結局、振り出しに戻って一から再作成することにしました。

Let’s Encrypt 証明書再作成

ウェブサーバー停止

まずは、80番ポートを利用しているウェブサーバーを停止

私の場合はnginxなので、

# service nginx stop

古い証明書関連ファイルやディレクトリを削除

下記に古いファイルやディレクトリが保存されているので、該当するドメインを削除します

  • /etc/letsencrypt/live/
  • /etc/letsencrypt/archive/
  • /etc/letsencrypt/renewal/

証明書新規作成

私の環境では、/var/opt/letsencrypt/に格納されているので、

# cd /var/opt/letsencrypt/
# ./certbot-auto certonly --standalone -d foo.bar.com

複数ドメインがある場合 -d オプション後に続けて明記するような記事もあるのですが、上手くいかなかったので、複数ある場合でも一つずつ行う必要がありました。

ウェブサーバー起動

# service nginx start

ここまでで証明書再作成作業は終了です。

メンテナンス

更新

期限まで30日未満のものを更新

# ./certbot-auto renew

全ての証明書を強制更新

# ./certbot-auto renew —force-renew

自動更新

更新切れを気にする必要がないように、cronで自動更新した方が楽です
毎月の1日に更新するように設定

# cd /etc/cron.d
# vi letsencrypt
0 0 1 * * root /var/opt/letsencrypt/certbot-auto renew --post-hook "service nginx restart"

QNAP再起動後にNFSでマウントできなかった

QNAPをNFSサーバーにして、各クラアントからAutofsでマウントして、正常に動作していたはずなのに、QNAPを再起動した後から、NFSによるマウントが出来なくなってしまった。

数台のクライアントからAutofsでQNAPにマウント出来ていたはずが、どれも、正常にマウントしない症状。

QNAP上のNFSを再起動してみても変わらずで、mountの詳細を見てみると、

mount.nfs: mount(2): Permission denied
mount.nfs: access denied by server while mounting 192.168.1.2:/data

明らかにサーバー側で拒否されてる

QNAPサーバー側では、接続してくるIPを制限しているので、QNAPへSSHで入り、/etc/exportsを確認してみた所、

“/share/MD0_DATA/data” 192.168.1.1192.168.1.1.2192.168.1.3(rw,async,no_subtree_check,insecure,no_root_squash)

許可するIP部分が勝手に連結されているのが原因でした。

exportsを書き換えても、ウェブ管理画面のGUIで設定を行うと再び連結されるので、QNAPマネージャーのバグなのでは?

仕方ないので、ウェブ管理画面上の権限設定→共有フォルダ→アクションボタンの共有フォルダ権限の編集→権限タイプの選択でNFSホストのアクセスに進み、接続を許可するIPを一つづつ記入し、適用する事で、各クライアントから正常にAutofsが働くようになった。

何だかんだQNAPのバグには悩まされる…


PHP5.6のgd-lastがyum更新で失敗する

CentOS/SL6のyumにて、いつも通り更新を行ってましたが、gd-lastで引っかかってました。

エラー: パッケージ: gd-last-2.2.5-1.el6.remi.x86_64 (remi)
要求: libwebp.so.5()(64bit)

libwebpを要求しているようなので、epelからlibwebpをインストールするだけで解決

epelがまだインストールされていない方は、
# yum -y install epel-release
# yum update
libwebpをインストール
# yum -y install libwebp --enablerepo=epel

gd-lastをインストール
# yum -y install gd-last --enablerepo=remi


Coreserverリニューアル後にWordPress閲覧不可に

Coreserver上にて、とあるブログサイトをWordPressで運用していたのですが、数日前から閲覧不可になってた。

どうやら、Coreserverにて大規模なリニューアルが行わたのが原因のようです。

https://www.coreserver.jp/info/brandnew2017/

CPUコア数やメモリ増強、SSD対応など機能的にはかなりアップしたようなのですが、PHP/MySQL/Apacheなども最新のバージョンが採用された影響で、今まで動作していたWordPressが動作しなくなってしまいました。

調べてみると、WordPress自体が動作していなく管理画面すら入れない状況でした。

画面上では、真っ白で何も表示されていないので、SSHでログインし、デバッグを有効にしてみました。
すると、下記のようなエラーが残されていました。

PHP Warning: require_once(/wp-content/plugins/db-cache-reloaded-fix/db-module.php)

db-cache-reloaded-fixのプラグインが既に更新されておらず、PHP71にも対応していないようなので、WordPress管理画面にも入れないのでプラグインディレクトリからdb-cache-reloaded-fixを除外。
しかし、それでも同様のエラーが表示されるので、キャッシュディレクトリ内を削除。
これでもエラーが解決されないので、プラグインディレクトリ自体をリネームしてみました。
やはり、同様のエラーが続くので、調べてみると、wp-content内にdb-cache-reloaded-fixがdb.phpを作成するらしく、これも削除しなければならないようでした。

そして、他のプラグインを戻してみましたが、やはりWordPressは動作せず。

仕方ないので、「PHPスクリプトが動かなくなりました」の対応通りにPHP5.xに戻してみたところ、一瞬だけWordPress画面だけ表示されましたが、すぐに真っ白な画面に戻った。

もうプラグインやテーマ内の不具合を探すのが億劫になってきて、新規にWordPressを作成し、MySQLのデータベースだけを読み込んでみた方がてっとり早いと思ったら、なんと文字化け。
エンコードをEUCやSHIS、UTF8など、どれを選択しても化ける。

PHPで構築したページが文字化けしている」を参考に、PHPやらMySQL関連を弄ってみるが、全てをUTF8になっているはずなのに、一向に文字化けが治らない。

さて、どうしたものかと、WordpressのMySQLデータ内部を覗いてみると、データ部が文字化けしている。
一週間前にDBのバックアップを取っていたので、それと比較してみた所、バックアップのDBは文字化けしていない事が判明。

結局、PHP71+MySQL5.7の最新バージョン上にて、WordPressを新規構築し、インポートしたバックアップのDBを読み込むことで、復旧した。

尚、Coreserver上でFast-cgiを利用する場合には、php.iniに相当するファイルも設定する必要があるので、下記を参考にすることもお忘れなく!

https://www.coreserver.jp/support/faq/php-cgi.php

1日がかりで疲れたわ。


ページ:1234567...26