office 2007 から2016 へ 乗り換え時 ACCESSがフリーズする

EXCEL2007 のサポート期限が迫っているので、

会社のexcel を 2007 → 2016 へ 変えました。

 

会社のシステムがEXCEL2007 ACCESS2007 を使用しているので、

移行がスムーズにいくか心配していましたが、2007をそのままに2016を

インストールしたところ、問題なく動作したようだったので、

ホッとして全てのPCにインストール作業を行いました。

 

しかし・・・。

数日して、

会社のシステムが何度かフリーズしました。

どうも呼びだしているACCESSが応答しなくなったようです。

 

会社のシステムは.NET で作成し、帳票等はACCESSEXCEL で出力しているのですが、今まで起きなかったフリーズが発生しています。

特に、ACCESSのレポートを呼び出したときに発生していたようです。

 

今更officeを元に戻すわけにはいかないので、古い2007をしっかり削除して、

それからもう一度office 2016をインストールしました。

以後、不具合は再現していません。

 

※ Creators Update 直後に頻発したので、要因としてあったのかもしれません。

 

パーフェクト PHP mini-blog

no route found と表示されてしまい、動かなかったので、

タイプミスかと思い、

サンプルコードをダウンロードして入れ替えてみたところ、

やはり、no route found 。。。

 

.htaccess は動作している。

それではドキュメントルートの問題か。

 

ドキュメントルートを/var/www/html/mini-blog.localhost/web から、

/var/www/htmlに戻して web/index.php/account/signup にアクセスしてみると、ちゃんと動きました。

原因は後日追求しますが、そういうこともあるということ。

CenteOS7 Bindの正引きがうまくいかない

会社の内向け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 解決!

 

PHP7.1 CentOS7 でのインストール時の障害

PHP7.1を インストールしようとしたところ、

なぜかPHP5がインストールされてしまう。。。。。

 

削除、インストールを繰り返してもうまくいかない。

 

remi71 ではなく、remi-safeからやったらできたのですが、

今度はPDOが認識されない。

 

あきらめて、php5で一日プログラミングし、仕事が完了したところで、

今朝、もう一度チャレンジしました。

 

昨日は、最初にremi71からインストールしようとしてなぜか 5.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 になってしまっていて、それでPHP5がインストールされていたようです。

コメント欄に書いてありました・・・・。

VB.net での エクセルのプロセス問題

アプリケーションで開いたエクセルを、ユーザーが閉じるのを待たなければいけない局面があります。

エクセルに書き込まれた内容を確かめてもらったりするばあい。

もしくは、書き込んでもらう時。

 

ループ内で、そのエクセルがあるかどうかをチェックして、なくなるのを待つように実装しました。

実装当時、開放しなくてもエクセルのプロセスは残りませんでした。

Windows10 になるまでは!

 

会社のPCがWindows10に移行してからしばらくして、

プロセスが残っていることに気づきました。

仕方がないので、エクセルのBeforeCloseのイヴェントをとらえて、

その中でプロセスの開放処理を書いたのですが、

 

社内システムのアプリの更新をかけた後に、

エラーが出ているとの報告が。

ログをチェックすると、いらなくなったエクセルのファイルを削除しようとしたときに、別のプロセスが使用中で削除できなくなっていました。

閉じたエクセルが、タイミングによって解放されずにぶつかってしまったようです。

 

GC.Collect() でガーベッジコレクションをクリアすることで解消することができました。

 

 

CentOS7 Samba で Windowsから共有フォルダにアクセスできない不具合

ファイルサーバの引っ越しを行ってきました。

 

弊社の拠点はVPNで接続されており、

社内LANとしてどの拠点にも気軽にアクセスできる状態です。

 

先日ある拠点のファイルサーバの引っ越し(windows10 のフォルダ共有→CentOS7 Samba) をおこない、クライアントのWindows10PCから接続してみると、

ユーザー、パスワードの入力画面が表示されるまでに 30秒以上かかり、襲時には1,2分かかっていました。??????

まあ、そのうち調子が出るのではないかと、頭をかしげながらその拠点のクライアントPCの設定をすべて終えました。

別の拠点に引っ越し完了をつたえて、パスワードを再設定してもらおうとすると、

なぜか全くアクセスできない。

試しに、私が勤務している拠点(勤務センターとする)のPCにリモートデスクトップでログインし、Sambaの共有フォルダにアクセスをこころみましたが、できませんでした。

ping も通らない。

前日まで勤務センターのPCからリモートでファイルサーバの設定を行っていたので何ともおかしな話です。

変わっているのは、IPぐらいのものですが、セグメントは変えていないし、

???アクセスできない意味が分からない。

 

意味が全く分からないので、引っ越しは断念、すべて元に戻してみんなに謝って帰りました。

サーバは持って帰り調査です。最悪すべて再インストールするしかないな、と思っていました。それでもだめならば、機器の初期不良か・・・。

 

不審だったところがいくつか。

1 IPを変更後にreboot したが、いつまでたっても起動しなかった。

  モニタを接続してみると、エラーメッセージが出て固まっていた。

 

2 サーバを設置した拠点のクライアントPCからはアクセスできるのだが、

  パスワード入力画面が出てくるのが異常に遅い。

3 VPNでつながっているほかの拠点からはアクセス不能。PINGも通らない。

 

1の再起動失敗は、OSのアップデートで起動しなくなったことがあったので、

無効にしているはずのカーネルのアップデートがされてしまったのか、

それとも機器の不良で不安定なのか・・・。

2、3は・・・意味が分からないが、LANケーブルの断線、HUBの不良、ルータのキャッシュの不具合を考えました。

 

どちらも間違い。

1は、おそらく途中でぶち切ってしまったシェルスクリプトが動作していて、

起動できないのではなくて、シャットダウンできない状態にあったようです。

エラーメッセージは a stop job is running for ・・・・・で、

タイムアウトにもならずに延々と待機していました。

一度強制終了してから、起動、そしてもう一度再起動すると、普通に起動するようになりました。

2,3はなんと、

一つのLANポートに2つのIPアドレスが設定されていました。

それも2つ目は別の拠点のIPでセグメントも違っていました。

これは、一度GNOMEIPアドレスをいじっていた時に、なぜかなってしまったようです。

一度デバイスを削除してから、Modifyしなおしたら治りました。

GNOMEでのIPアドレスの変更や追加は、やらない方が無難なようです。

 

かくしてファイルサーバの引っ越しは完了。ようやく終わりました。

 

CentOS7 /dev/mapper/cl-root の inode が 使用率100% になる

会社で稼働中のファイルサーバが、朝出勤したら止まっていました。

smb nmb の状態を見ると何かエラーが出ているもよう。

 

夜中に行っているウィルスチェックやバックアップの結果メールを見ると。

システム動作情報ファイルに書き込みができません: デバイスに空き領域がありません」

 

というメールがバックアップ開始から40分後に来ていました。

 

???

バイスに空きがない・・・。そんなはずはないので調べると、

df -i

/dev/mapper/cl-root  100%

inode が枯渇しています。

意味が分からないので、うろうろと調べてみたがよく分からない。

しかしバックアップの後にエラーが出ているので、

バックアップ先のUSBハードディスクを疑いました。

まずは、ls -l してみると、どうもマウントされたままのようです。

アンマウントして ls ・・・。なんかフォルダがそのままある。

マウントしたUSBHDに存在するはずのフォルダが、

アンマウントした状態でも存在します。

削除してみると・・・、inode  1% まで下がりました。

他のサーバもチェックしましたが、同様の現象は起きていませんでした。

USBHDをフォーマットしたり、バックアップのチェックをしているうちになったのか、それともスクリプトが悪いのか。

うーむ。もしかすると、マウントに失敗して、mkdir したとか。

もう一度スクリプトを見直してみることにします。