:::: MENU ::::
Browsing posts in: Linux

yum updateで重複するパッケージのエラーで更新できない

CentOS7上にて、yum updateを行った際に、「〜の複製です」とduplicateエラーにて更新出来ない状況に陥ったので、いろんな解決方法を試してみた。

# yum update

....
yum-utils-1.1.31-42.el7.noarch は yum-utils-1.1.31-40.el7.noarch の複製です
zsh-5.0.2-28.el7.x86_64 は zsh-5.0.2-25.el7_3.1.x86_64 の複製です

package-clenupで直す

  • package-clenupがない場合は、yum-utilsをインストール
# yum install yum-utils
  • 重複するパッケージを削除
# package-cleanup --dupes

package-cleanupで直らない場合

# LANG=C
# yum check duplicates | awk '/is a duplicate/ {print $6}' > /tmp/yum.dupes
# cat /tmp/yum.dupes
....
1:yelp-3.14.2-1.el7.x86_64
1:yelp-libs-3.14.2-1.el7.x86_64
yelp-xsl-3.14.0-1.el7.noarch
yum-plugin-fastestmirror-1.1.31-40.el7.noarch
yum-utils-1.1.31-40.el7.noarch
zsh-5.0.2-25.el7_3.1.x86_64
# yum remove `cat /tmp/DUPES`

別な方法

How to remove duplicate packages from a failed yum transaction (when yum-complete-transaction fails to complete)

# yum-complete-transaction
# tar cjf /tmp/rpm_db.tar.bz2 /var/lib/{rpm,yum}
# yum check &> /tmp/yumcheck
# grep "duplicate" /tmp/yumcheck | awk '{ print $NF }' | egrep -v "\:" > /tmp/duplicaterpms
# grep "duplicate" /tmp/yumcheck | awk '{ print $NF }' | egrep ":" | awk -F':' '{ print $NF }' >> /tmp/duplicaterpms
# for i in $(cat /tmp/duplicaterpms)
do
rpm -e --justdb --nodeps $i
done

これで直った!


CentOS6上にRSSリーダーのTinyTinyRSSを導入

CentOS6上にtiny tiny rssを導入

必要条件

  • PHP 5.6以上
  • Postgresql9.1以上 or MySQL InnoDB
  • SSL証明書(letsencrypt)
  • Git
  • http環境(Apache,nginx)
  • DNS

はじめに

Tiny Tiny RSS のダウンロード

導入するディレクトリ及びオーナー・グループ(nginx)は適宜変更

# cd /var/www/html
# git clone https://tt-rss.org/git/tt-rss.git tt-rss
# chown -R nginx:nginx tt-rss

DB の作成 (admin/password)

※DB名:tt-rss、DBユーザ名:admin、DBユーザパスワード:password とする場合

# mysql -u root -p
mysql> CREATE USER ‘admin'@'localhost' IDENTIFIED BY 'password';
mysql> CREATE DATABASE tt-rss CHARACTER SET utf8;
mysql> GRANT ALL ON DB_NAME.* TO ‘admin'@'localhost’;

または、下記

DNS

(自分のサイトURL配下に設置する場合は、DNSの設定は必ずしも必要ではありません。)
私の場合、CloudFlareにてreader.yoursite.comの名前でDNS作成
(サイト名は自分用に設定してください)

letsencryptで証明書作成

$ certbot certonly --standalone -d reader.yoursite.com

nginxのconf作成(SSL対応)

tt-rss/utils/gitlab-ci/nginx-defaultが雛形
https://gist.github.com/bjoerns1983/30dff232c8ccede12f6caec7c609b0b6

server_name reader.yoursite.com;

location / {
root /var/www/html/tt-rss;
charset utf-8;
index index.php;

try_files $uri $uri/ /index.php?q=$uri&$args;

include php_exec;
}

# すべての不可視ファイルをアクセス不可にします。
location ~ /\. {
access_log off;
log_not_found off;
deny all;
}
listen 443 ssl http2; # managed by Certbot
by Certbot
ssl_session_timeout 1440m; # managed by Certbot

ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # managed by Certbot
ssl_prefer_server_ciphers on; # managed by Certbot

128-SHA ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES256-SHA384 DHE-RSA-AES128-GCM-SHA25
6 DHE-RSA-AES256-GCM-SHA384 DHE-RSA-AES128-SHA DHE-RSA-AES256-SHA DHE-RSA-AES128
-SHA256 DHE-RSA-AES256-SHA256 EDH-RSA-DES-CBC3-SHA"; # managed by Certbot

if ($scheme != "https") {
}

tt-rss設定

https://reader.yoursite.com/install/へアクセスし、各項目を設定

  • MySQLの設定など
  • DBホスト名やPortも記述したほうが良い
  • 確認のため、config.phpを見ておく
  • 初期化

パスワード変更

admin/passwordでログインし、パスワードを変更しておく

ユーザー作成

  • 言語を日本語
  • タイムゾーンをAsia/Tokyo
  • APIにチェックマーク

外部サービスからインポート

inoreaderの場合
inoreaderからエクスポートし、subscription.xmlをインポートする。
この辺は、GoogleやFeedlyでも同様

ちょっとしたエラー

  • インポートで500 Internal Sever Errorが出る場合
    (config.php内にホスト名・ポート番号が未記入もしくはmysqlでflush privilegesが必要だった?)
  • 記事の更新が出来ていない・出来ない
    下記のディレクトリーを書き込み可にする必要があるようだ。
# chmod -R 777 lock feed-icons cache/export cache/images cache/upload

定期的に更新

rootだと動作しないのでnginxで動作させる

# sudo -u nginx crontab -e
*/15 * * * * /usr/bin/php /var/www/html/tt-rss/update.php --feeds --quiet

Tiny RSSの更新(アップデート)

# cd /var/www/html/tt-rss && git pull

muninでエラーメールが頻繁に届くので対処

以前から、muninで監視されているサーバーから、下記のエラーメールが届いてて、放置状態だったので、対処した。

エラー内容

[FATAL] There is nothing to do here, since there are no nodes with any plugins. Please refer to http://munin-monitoring.org/wiki/FAQ_no_graphs at /usr/share/munin/munin-html line 40

このエラーは、muninサーバーではなく、監視されているmunin-nodeを動作しているサーバーで起きている

プラグインによるエラーだと、ほぼ、このコマンドで解消される

munin-node-configure --shell | sh -x

しかし、これでも解消されず、エラーを吐いているmunin-nodeのサーバー設定を見てみると、なぜかmunin.confが存在している。

通常、監視されているサーバーでは、munin-nodeだけインストールすれば良いのだが、どうやらmuninもインストールされていたようだ。

したがって、muninを削除し、解消された。

もし、削除しなければ、munin.confを下記の設定にて解消されるはず。

/etc/munin/munin.conf

[localhost] 

address 127.0.0.1 

use_node_name yes

今回の対処では、こちらの記事を参考にさせていただきました
https://mgng.mugbum.info/1454


etckeeperで肥大した/etcをクリーンアップ

Linuxで/etcに変更があった場合に、自動的に保存してくれるetckeeperがありますが、使っていくうちに/etc/.git内にファイルが溜まっていく為、/etcが肥大化していきます。

私の環境でも、

# du -hsc /etc/.git
16G /etc/.git
16G 合計

なんと、16GBも容量が肥大しておりました

なので、gitのクリーンアップオプションで整理(クリーンアップは自己責任で行ってください)

# cd /etc/
# git gc
# du -hsc /etc/.git
56M /etc/.git
56M 合計

かなりスッキリしました。

Etckeeperは便利ですが、yumで更新が大量に入ると、圧縮に時間がかかってしまうので、総じて作業時間がかかってしまうのが難点ですね


PHPのUse of undefined constant警告の対処

php-fpmのログに下記の警告が出てた

PHP Warning:  Use of undefined constant ’128M’ - assumed '’128M’' (this will throw an Error in a future version of PHP)

WordPressのwp-config.phpにmemory limit設定に128Mを指定した欄が該当していたらしく、この欄だけアポストロフィー表記になっていました。

対策は、「‘」「’」を半角のシングルクォーテーション「’」へ変更する事で解決です。

phpコーディングでは、シングルクォーテーションにしておいた方が無難です。
また、ネット上からコピペする際は、アポストロフィーになっている事が多いので注意が必要ですね。


CentOS6系のPHP5.xを7.xへアップデート

CentOS6系のPHP5.xをPHP7.xに更新したメモ

環境

ここのサーバーでは、下記の環境でphp7.3更新作業を行いました
Scientific Linux 6.9
nginx
php-fpm
php5.6

更新前に作業

php5.xを削除するので、/etc/php.iniのバックアップ
php-fpmも再設定が必要なので、/etc/php-fpm.d/www.confをバックアップ

現在のPHP確認

$ php -v
PHP 5.6.35 (cli) (built: Mar 29 2018 07:37:47)
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies

旧バージョンの削除

# yum remove php-*
(zshだと php-¥*)

epelとremiのインストール確認

remiは6系のものでOK
(remiは最新のもので、priority=1)推薦

# vi /etc/yum.repos.d/remi-php73.repo
[remi-php73]
priority=1
....

/etc/yum.repo.d/内にremi-php7*.repoがあることを確認

念の為、yumのキャッシュを削除

# yum clean all

7.xをインストール

nginx版
# yum install --enablerepo=remi-php73 php php-fpm php-mcrypt php-cli php-common php-devel php-gd php-mbstring php-mysqlnd php-opcache php-pdo php-pear php-pecl-apcu php-pecl-zip php-process php-xml

Apache版
# yum -y install --enablerepo=remi,remi-php73 php php-devel php-mbstring php-mysql php-pdo php-gd

補足:——————————————————————
libargon2の依存関係でアップデート処理が止まる場合は、remiのリポジトリを最新にするか再インストール
https://www.riscascape.net/archives/16990

php7.3の確認

$ php -v
PHP 7.3.0 (cli) (built: Dec 4 2018 20:10:48) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.0-dev, Copyright (c) 1998-2018 Zend Technologies
with Zend OPcache v7.3.0, Copyright (c) 1999-2018, by Zend Technologies

ZendEngineもZendOPcacheに変更され、APCuも導入済みとなっております

OPcache、APCuの設定については、初期設定のまま使用します

php-fpmの設定

下記環境は、個々に違いがあるので自分の環境に合わせてくださいね

# vi /etc/php-fpm.d/www.conf
listen = 127.0.0.1:9000
listen.owner = nobody
listen.group = nobody
listen.mode = 0660
user = apache
group = apache
pm = static

保存後、php-fpmを再起動します。

# /etc/init.d/php-fpm restart

php.iniの再設定

default_charset = UTF-8
mbstring.language = Japanese
mbstring.encoding_translation = Off
mbstring.detect_order = UTF-8,SJIS,EUC-JP,JIS,ASCII
date.timezone = Asia/Tokyo
expose_php = Offmemory_limit = 128M
post_max_size = 128M
upload_max_filesize = 128M
memory_limit = 128M
date.timezone = "Asia/Tokyo"

保存後、nginx再起動

# /etc/init.d/nginx restart


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/


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 [email protected]:user/repo
  • ssh鍵の登録
    etckeeper側ホストでrootにて、鍵がなければを作成する(パスは空で)

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

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

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

Source Bitbucket 2018 02 06 12 44 43  Account settings Bitbucket 2018 02 06 12 45 38

Ssh keys Bitbucket 2018 02 06 12 46 30

自動実行

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へ移行したほうが賢明なのはわかっているのですがね・・


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のバグには悩まされる…


ページ:1234567...16