0 comments 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で更新が大量に入ると、圧縮に時間がかかってしまうので、総じて作業時間がかかってしまうのが難点ですね
0 comments 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コーディングでは、シングルクォーテーションにしておいた方が無難です。
また、ネット上からコピペする際は、アポストロフィーになっている事が多いので注意が必要ですね。
0 comments ここのサーバーでは、下記の環境で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 -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-¥*)
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 clean all
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
$ 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の設定については、初期設定のまま使用します
下記環境は、個々に違いがあるので自分の環境に合わせてくださいね
# 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
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
0 comments 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/
0 comments 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を再起動、キャッシュの削除、クッキーの削除を行ってみましょう。
0 comments 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へ変更
再度、再発行コマンドで無事通りました
0 comments /etcをGit管理出来るetckeeperは以前か知っていたのだが、放置したままだったので、今更導入してみた。
# yum -y install etckeeper --enablerepo=epel
# ap-get -y install etckeeper
/etc/etckeeper/etckeeper.confの下記箇所を確認及び追記
VCS="git" PUSH_REMOTE="origin"
# cd /etc/ # etckeeper init
# git remote add origin git_url
# etckeeper commit -m 'first commit'
githubでもやることは同じ
# git remote add origin [email protected]:user/repo
# sh -c 'ssh-keygen ; less /root/.ssh/id_rsa.pub’
表示されたssh鍵をbitbucket側に登録する
注意することは、作成したリポジトリの設定でSSH鍵を登録するのでなく、アカウント設定欄からSSH鍵を登録すること。
各リポジトリ設定でssh鍵を登録するとリードオンリーとなりアクセス拒否されてしまいます。
etckeeperをインストールした時点で、/etc/cron.dailyにスクリプトが作成されるので、毎日自動で/etc内を更新してくれるようになっています。
一度、手動実行して、無事に登録出来るのか確認してみると良いでしょう。
# /etc/cron.daily/etckeeper
0 comments 職場のサーバーで、未だに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へ移行したほうが賢明なのはわかっているのですがね・・
0 comments VirtualBoxは、１年に数回しか起動しないので、久しぶりに起動すると、アップデートを必ず促されるので、アップデートを行っていますが、毎回、Mac版VirtualBoxのインストーラーが検証中のまま進まないので、メモしておく。
https://forums.virtualbox.org/viewtopic.php?f=8&t=77122
sudo installer -package /Volumes/VirtualBox/VirtualBox.pkg -target /
なお、システム環境設定のセキュリティとプライバシー内の、ダウンロードしたアプリケーションの実行許可を「すべてのアプリケーションを許可」にしておく事も必要かもしれません。
0 comments SSL証明書では、Lets’s Encryptの証明書を利用しているのですが、期限が3ヶ月なので、ちょっと油断していると証明書切れになります。
事前に、証明書を更新する通知も来るのですが、後回しにしていたら、期限が切れてしまいましたので、再作成しました。
再作成なので、certbot-auto renewすればいいんじゃね？
しかし、renewだけじゃ、証明書が期限切れのままでダメでした。
なので、結局、振り出しに戻って一から再作成することにしました。
まずは、80番ポートを利用しているウェブサーバーを停止
私の場合はnginxなので、
# service nginx stop
下記に古いファイルやディレクトリが保存されているので、該当するドメインを削除します
私の環境では、/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"