:::: MENU ::::

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

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

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

証明書新規作成

私の環境では、/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日がかりで疲れたわ。


Dockerのインストール方法が変わってた

DockerがCE/EEとなり、インストール方法が変わってるんですね。

公式やQuiita参照で、ほぼ解決します

https://docs.docker.com/engine/installation/linux/docker-ce/debian/#prerequisites

http://qiita.com/adnap2501/items/e00248dd697059969203

古いバージョンをアンイストして、入れたほうが良いかもしれません。

新しいリポジトリ追加して、apt更新時に上手く取得できない症状に遭遇しましたが、
そのままインストールしちゃいました。

docker-composeもaptでインストール出来るので楽ですね

ちなみに、Redhat/CentOS系は下記のQuiitaで良いでしょう

http://qiita.com/sawadashota/items/2bed41598d825d488701



dyld: Library not loaded: /usr/local/opt/jpeg/lib/libjpeg.8.dylib

久しぶりにHomebrewでUpgradeかけたら、下記のエラーが出た

dyld: Library not loaded: /usr/local/opt/jpeg/lib/libjpeg.8.dylib

ほぼ、下記の記事が参考になる

http://qiita.com/maimai-swap/items/9ba6e5f877274079d755

私の環境の場合、jpegのバージョン8d,9bが混在しているようなので、下記のコマンドで戻せばOKでした。

# brew switch jpeg 8d

ページ:1234567...26