会社の内向けDNSサーバを構築しました。
はまったところを。
/usr/libexec/setup-named-chroot.sh /var/named/chroot on
bind-chrootでやる場合は必要のようです。
インストール直後に行います。
正引きようのファイル
$TTL 86400
@ IN SOA blueserver.hsmt. root.blueserver.hsmt.(
2017062001 ; Serial
28800 ; Refresh
14400 ; Retry
3600000 ; Expire
86400 ) ; Minimum
IN NS blueserver.hsmt.
IN MX 10 blueserver.hsmt.
@ IN A 192.168.1.10
* IN A 192.168.1.10
redserver IN A 192.168.1.20
この設定だと、なぜかblueserver.hsmt は解決できるのだが、redserver.hsmtは解決できない・・・。いろいろ試した結果、redserver.blueserver.hsmtは解決できる！！
なので変更しました。
@ IN SOA hsmt.net. root.hsmt.net
2017062001 ; Serial
28800 ; Refresh
14400 ; Retry
3600000 ; Expire
86400 ) ; Minimum
IN NS blueserver.hsmt.net.
IN MX 10 blueserver.hsmt.net.
@ IN A 192.168.1.10
* IN A 192.168.1.10
redserver IN A 192.168.1.20
これでいけました。 redserver.hsmt.net 解決！
****************************************************************************************************
※追記 インクルードしているゾーンファイルに問題がありました。
zone "blueserver.hsmt"{
type master;
file "blueserver ～
→ 正しくは
zone "hsmt.net"
と hsmt.net を正しく定義してあげます。
PHP7.1を インストールしようとしたところ、
なぜかPHP5がインストールされてしまう。。。。。
削除、インストールを繰り返してもうまくいかない。
remi71 ではなく、remi-safeからやったらできたのですが、
今度はPDOが認識されない。
あきらめて、php5で一日プログラミングし、仕事が完了したところで、
今朝、もう一度チャレンジしました。
昨日は、最初にremi71からインストールしようとしてなぜか ５．XXが入り、
次にremi-safe を使用したところPDOが使用できないので、
あきらめてもう一度remi71から、とやったら、
「～が 衝突しています。」
とエラーが出てインストール不能に。
仕方がないので、普通に yum install php とやったら何とかphp5の環境に戻せました。
さて。
まずはインストール済みのパッケージを確認します。
# rpm -qa | grep php > php-mysql-5.4.16-42.el7.x86_64 > php-5.4.16-42.el7.x86_64 > php-pdo-5.4.16-42.el7.x86_64 > php-mbstring-5.4.16-42.el7.x86_64 > php-cli-5.4.16-42.el7.x86_64 > php-common-5.4.16-42.el7.x86_64
そして削除。
yum erase php71-php-json-7.1.5-1.el7.remi.x86_64 php-mbstring-5.4.16-42.el7.x86_64 php-pdo-5.4.16-42.el7.x86_64 php71-php-common-7.1.5-1.el7.remi.x86_64 php-5.4.16-42.el7.x86_64 php-cli-5.4.16-42.el7.x86_64 php71-php-cli-7.1.5-1.el7.remi.x86_64 php71-runtime-1.0-1.el7.remi.x86_64 php-mysql-5.4.16-42.el7.x86_64 php-common-5.4.16-42.el7.x86_64
ここまではhttp://qiita.com/ichi_404/items/48375a0a38f013679758 を参考にしています。
そしてインストール
yum install --enablerepo=remi-php71 php php-cli php-common php-devel php-fpm php-gd php-mbstring php-mysqlnd php-pdo php-pear php-pecl-apcu php-soap php-xml php-xmlrpc
衝突が・・・。
ipa-client-4.4.0-14.el7.centos.7.x86_64 は次のインストール済みと衝突しています: freeipa-client: ipa-client-4.4.0-14.el7.centos.7.x86_64
ipa-client-common-4.4.0-14.el7.centos.7.noarch は次のインストール済みと衝突しています: freeipa-client-common: ipa-client-common-4.4.0-14.el7.centos.7.noarch
ipa-common-4.4.0-14.el7.centos.7.noarch は次のインストール済みと衝突しています: freeipa-common: ipa-common-4.4.0-14.el7.centos.7.noarch
さて、よく考えてみれば、衝突しているならばremoveすればいいのではないか。
yum remove freeipa-cient
yum remove freeipa-client-common
yum remove freeipa-commmon
よし！
まだエラーが・・・・・・。
『エラー: パッケージ: php-pecl-apcu-5.1.8-1.el7.remi.7.1.x86_64 (remi-php71)
要求: php(zend-abi) = 20160303-64
インストール中: php-common-5.4.16-42.el7.x86_64 (base)
php(zend-abi) = 20100525-64
エラー: パッケージ: php-pecl-apcu-bc-1.0.3-6.el7.remi.7.1.x86_64 (remi-php71)
要求: php(zend-abi) = 20160303-64
インストール中: php-common-5.4.16-42.el7.x86_64 (base)
php(zend-abi) = 20100525-64
エラー: パッケージ: php-pecl-apcu-bc-1.0.3-6.el7.remi.7.1.x86_64 (remi-php71)
要求: php(api) = 20160303-64
インストール中: php-common-5.4.16-42.el7.x86_64 (base)
php(api) = 20100412-64
エラー: パッケージ: php-pecl-apcu-5.1.8-1.el7.remi.7.1.x86_64 (remi-php71)
要求: php(api) = 20160303-64
インストール中: php-common-5.4.16-42.el7.x86_64 (base)
php(api) = 20100412-64
問題を回避するために --skip-broken を用いることができます。
これらを試行できます: rpm -Va --nofiles --nodigest』
さて、今度はここで https://www.lancork.net/2016/05/yum-centos67-php7-install/
を参考に、リポジトリの優先度を変更します。
・・・・・。できました。
落ち着いて、あきらめずに、頑張ろう。
適当にやらないことを自戒しておきます。
※ 実は複数のサイトで、--enablerepo=remi-php71
が -enablerepo=remi-php71 になってしまっていて、それでPHP５がインストールされていたようです。
コメント欄に書いてありました・・・・。
追記：PHPEXCELを使用する場合は、
yum install --enablerepo=remi-php71 php php-cli php-common php-devel php-fpm php-gd php-mbstring php-mysqlnd php-pdo php-pear php-pecl-apcu php-soap php-xml php-xmlrpc php-pecl-zip
また、これでPHPのバージョンが
7.13 から 7.18に 上がりました。
アプリケーションで開いたエクセルを、ユーザーが閉じるのを待たなければいけない局面があります。
エクセルに書き込まれた内容を確かめてもらったりするばあい。
もしくは、書き込んでもらう時。
ループ内で、そのエクセルがあるかどうかをチェックして、なくなるのを待つように実装しました。
実装当時、開放しなくてもエクセルのプロセスは残りませんでした。
Windows10 になるまでは！
会社のPCがWindows10に移行してからしばらくして、
プロセスが残っていることに気づきました。
仕方がないので、エクセルのBeforeCloseのイヴェントをとらえて、
その中でプロセスの開放処理を書いたのですが、
社内システムのアプリの更新をかけた後に、
エラーが出ているとの報告が。
ログをチェックすると、いらなくなったエクセルのファイルを削除しようとしたときに、別のプロセスが使用中で削除できなくなっていました。
閉じたエクセルが、タイミングによって解放されずにぶつかってしまったようです。
GC.Collect() でガーベッジコレクションをクリアすることで解消することができました。
ファイルサーバの引っ越しを行ってきました。
弊社の拠点はVPNで接続されており、
社内LANとしてどの拠点にも気軽にアクセスできる状態です。
先日ある拠点のファイルサーバの引っ越し（windows10 のフォルダ共有→CentOS7 Samba) をおこない、クライアントのWindows10PCから接続してみると、
ユーザー、パスワードの入力画面が表示されるまでに ３０秒以上かかり、ひどい時には１，２分かかっていました。？？？？？？
まあ、そのうち調子が出るのではないかと、頭をかしげながらその拠点のクライアントPCの設定をすべて終えました。
別の拠点に引っ越し完了をつたえて、パスワードを再設定してもらおうとすると、
なぜか全くアクセスできない。
試しに、私が勤務している拠点（勤務センターとする）のPCにリモートデスクトップでログインし、Sambaの共有フォルダにアクセスをこころみましたが、できませんでした。
ping も通らない。
前日まで勤務センターのPCからリモートでファイルサーバの設定を行っていたので何ともおかしな話です。
変わっているのは、IPぐらいのものですが、セグメントは変えていないし、
？？？アクセスできない意味が分からない。
意味が全く分からないので、引っ越しは断念、すべて元に戻してみんなに謝って帰りました。
サーバは持って帰り調査です。最悪すべて再インストールするしかないな、と思っていました。それでもだめならば、機器の初期不良か・・・。
不審だったところがいくつか。
１ IPを変更後にreboot したが、いつまでたっても起動しなかった。
モニタを接続してみると、エラーメッセージが出て固まっていた。
２ サーバを設置した拠点のクライアントPCからはアクセスできるのだが、
パスワード入力画面が出てくるのが異常に遅い。
３ VPNでつながっているほかの拠点からはアクセス不能。PINGも通らない。
１の再起動失敗は、OSのアップデートで起動しなくなったことがあったので、
無効にしているはずのカーネルのアップデートがされてしまったのか、
それとも機器の不良で不安定なのか・・・。
２、３は・・・意味が分からないが、LANケーブルの断線、HUBの不良、ルータのキャッシュの不具合を考えました。
どちらも間違い。
１は、おそらく途中でぶち切ってしまったシェルスクリプトが動作していて、
起動できないのではなくて、シャットダウンできない状態にあったようです。
エラーメッセージは a stop job is running for ・・・・・で、
タイムアウトにもならずに延々と待機していました。
一度強制終了してから、起動、そしてもう一度再起動すると、普通に起動するようになりました。
２，３はなんと、
一つのLANポートに2つのIPアドレスが設定されていました。
それも２つ目は別の拠点のIPでセグメントも違っていました。
これは、一度GNOMEでIPアドレスをいじっていた時に、なぜかなってしまったようです。
一度デバイスを削除してから、Modifyしなおしたら治りました。
GNOMEでのIPアドレスの変更や追加は、やらない方が無難なようです。
かくしてファイルサーバの引っ越しは完了。ようやく終わりました。
会社で稼働中のファイルサーバが、朝出勤したら止まっていました。
smb nmb の状態を見ると何かエラーが出ているもよう。
夜中に行っているウィルスチェックやバックアップの結果メールを見ると。
「システム動作情報ファイルに書き込みができません: デバイスに空き領域がありません」
というメールがバックアップ開始から４０分後に来ていました。
？？？
デバイスに空きがない・・・。そんなはずはないので調べると、
df -i
/dev/mapper/cl-root 100%
inode が枯渇しています。
意味が分からないので、うろうろと調べてみたがよく分からない。
しかしバックアップの後にエラーが出ているので、
バックアップ先のUSBハードディスクを疑いました。
まずは、ls -l してみると、どうもマウントされたままのようです。
アンマウントして ls ・・・。なんかフォルダがそのままある。
マウントしたUSBHDに存在するはずのフォルダが、
アンマウントした状態でも存在します。
削除してみると・・・、inode 1% まで下がりました。
他のサーバもチェックしましたが、同様の現象は起きていませんでした。
USBHDをフォーマットしたり、バックアップのチェックをしているうちになったのか、それともスクリプトが悪いのか。
うーむ。もしかすると、マウントに失敗して、mkdir したとか。
もう一度スクリプトを見直してみることにします。
先日導入したSambaサーバが、急にアクセスできなくなったと連絡が入りました。
あきらめて現場にいる人に、電源長押しで、再起動してもらいました。
再起動すると接続できたので、/var/log/messages の、その時刻のところを見ると、
最後に残っていたのは、MasterBlowser 変更の通知でした。
/var/log/samba/nmbd.log を確認すると、
他のWindowsServer と、Master Blowser を取り合っていたようで、
nmbd のログは、Master Blowser 変更の記述でいっぱいでした。
SambaにはMasterBlowser をあきらめてもらうことにして、様子を見ています。
smb.conf に追加↓
domain master = no
local master = no
preferred master = no
os level = 0
