2018年03月
2018年03月31日
Acrobat Reader DC のツールペインを閉じる
PDFをひらくとき、画面の3分の1を占有する、ツールボックスの表示が非常に邪魔でした。
これを閉じた状態で保存することができるようです。
上記参考サイトの通りですが以下の手順。
編集 - 環境設定 から 文書をクリック。
「ツールパネルの現在の状態を記憶」 にチェックを入れます。
定期的なバージョンアップで毎回困っています。解決してよかった。
PDFをひらくとき、画面の3分の1を占有する、ツールボックスの表示が非常に邪魔でした。
これを閉じた状態で保存することができるようです。
上記参考サイトの通りですが以下の手順。
編集 - 環境設定 から 文書をクリック。
「ツールパネルの現在の状態を記憶」 にチェックを入れます。
定期的なバージョンアップで毎回困っています。解決してよかった。
2018年03月30日
ロードバランサー環境となっています。
複数のサーバーで、負荷分散しながらサイトを公開しています。
単純なミスが原因なのですが、メモ。
あるとき、フォルダ構成を整理整頓するために、不要と思われるフォルダやファイルを次々と消していました。
僕の管理しているサーバーでは、/var/www 以下に、
SiteA/
SiiteB/
という形で配置していました。そしてそこには test/ とか a/ とか。中には default/ とか。
そういう意味不明のファイルやフォルダがあったのです。
あるとき、この不明のファイルを削除したいという話がありました。僕はそれらを利用していないと考えていましたし、フォルダ作成については、コンテンツ管理者に任せていました。だからコンテンツ管理者が不要だと考え、それらのファイルを削除することにはなんの問題も無いと思っていました。
ファイルをコンテンツ管理者が削除してから、僕のところに連絡がきました。サイトの一部がタイムアウトになってしまい、閲覧できない。と。
そして現在、コンテンツの移動などもやっており、移動作業に問題があるのか、サーバーの設定ミスがあるのか。。。サーバーの方も確認してほしい。そのように言われたのです。
上記のファイル削除との関連性はまったく無いと思っていたので、移動作業によってサーバーの負荷が高くなりもっさりしているのだろうか・・・そのように考えていました。
ロードバランサー配下にあるサーバーにたいして、1台ずつアクセスすると、すべてのサーバーで問題無く動作していることがわかりました。
ということは、ロードバランサーを経由すると、うまくアクセス出来ないことになります。
しかしロードバランサーのせっていというのはほとんどなく、あり得るとしたらパケットフィルタなどがアクセスを拒否しているとか。。。そういうことぐらいしか思いつきませんでした。
ロードバランサーの設定を確認していると、ロードバランスする対象の各Webサーバーがすべてダウンとして認識されていることが分かりました。これではロードバランサーにきたアクセスは、振り分け先がないということで、エラーになっていたのだとわかりました。
原因はコンテンツファイルの削除でした。
ロードバランサーは、/a フォルダ内の index フィルを参照していました。このファイルがなくなったため、現在のサーバーステータスがダウンと判定されたようです。
ということで、ステータス監視用のファイルを改めて作成しなおして、それを間違えて消さないように注意したいと思います。
複数のサーバーで、負荷分散しながらサイトを公開しています。
単純なミスが原因なのですが、メモ。
あるとき、フォルダ構成を整理整頓するために、不要と思われるフォルダやファイルを次々と消していました。
僕の管理しているサーバーでは、/var/www 以下に、
SiteA/
SiiteB/
という形で配置していました。そしてそこには test/ とか a/ とか。中には default/ とか。
そういう意味不明のファイルやフォルダがあったのです。
あるとき、この不明のファイルを削除したいという話がありました。僕はそれらを利用していないと考えていましたし、フォルダ作成については、コンテンツ管理者に任せていました。だからコンテンツ管理者が不要だと考え、それらのファイルを削除することにはなんの問題も無いと思っていました。
ファイルをコンテンツ管理者が削除してから、僕のところに連絡がきました。サイトの一部がタイムアウトになってしまい、閲覧できない。と。
そして現在、コンテンツの移動などもやっており、移動作業に問題があるのか、サーバーの設定ミスがあるのか。。。サーバーの方も確認してほしい。そのように言われたのです。
上記のファイル削除との関連性はまったく無いと思っていたので、移動作業によってサーバーの負荷が高くなりもっさりしているのだろうか・・・そのように考えていました。
ロードバランサー配下にあるサーバーにたいして、1台ずつアクセスすると、すべてのサーバーで問題無く動作していることがわかりました。
ということは、ロードバランサーを経由すると、うまくアクセス出来ないことになります。
しかしロードバランサーのせっていというのはほとんどなく、あり得るとしたらパケットフィルタなどがアクセスを拒否しているとか。。。そういうことぐらいしか思いつきませんでした。
ロードバランサーの設定を確認していると、ロードバランスする対象の各Webサーバーがすべてダウンとして認識されていることが分かりました。これではロードバランサーにきたアクセスは、振り分け先がないということで、エラーになっていたのだとわかりました。
原因はコンテンツファイルの削除でした。
ロードバランサーは、/a フォルダ内の index フィルを参照していました。このファイルがなくなったため、現在のサーバーステータスがダウンと判定されたようです。
ということで、ステータス監視用のファイルを改めて作成しなおして、それを間違えて消さないように注意したいと思います。
2018年03月29日
teraterm-4.97.exe が Trojan:Win32/Vigorf.A といわれる
上記ブログと全く同じでした。
別でインストールされているアンチウイルスソフトは全く検知していなかったため、誤検知なのだと思われました。
関連情報では、どこかのタイミングの更新で解決しているようでしたが、僕の環境の windows server 2016 の本日現在ではダメでした。ちゃんとアップデートしているサーバーなんだけどな。。。アンインストールしてしまったので詳細なバージョンは不明です。
上記ブログと全く同じでした。
別でインストールされているアンチウイルスソフトは全く検知していなかったため、誤検知なのだと思われました。
関連情報では、どこかのタイミングの更新で解決しているようでしたが、僕の環境の windows server 2016 の本日現在ではダメでした。ちゃんとアップデートしているサーバーなんだけどな。。。アンインストールしてしまったので詳細なバージョンは不明です。
stock_value at 17:13｜この記事のURL│Comments(0)
2018年03月28日
2018年03月27日
2018年03月26日
2018年03月25日
Wsusは本気で運用しないとかえって手間がかかります。そのように僕は考えているので、あまりWSUSを触っていませんでした。
検証で短期間利用したら、すぐに標準のMSからのダウンロードに変えてしまうのです。
とは言っても、メンテナンスも必要なので以下の通りです。
WSUS クリーンアップ ウィザードのタイムアウトが解決したよ
--- 上記から引用 ---
USE SUSDB ;
GO
EXEC sp_configure 'remote query timeout', 0 ;
GO
RECONFIGURE ;
GO
-----------------------
MMCで管理しているときに、すぐにタイムアウトになってしまうように感じました。上記コマンドでタイムアウトしないということです。が、それでもまだやっぱりエラーになっています。サーバーのスペックの問題なのでしょうが、うーーーん。
不要な更新プログラムは「拒否済み」に設定しよう！
上記ブログは若干文体が異なりますね。ノリが軽いような文章です。
しかし重要なことがかいてあります。WSUSはこのMSブログが結構しっかりしているので、個々をチェックすれば、海外サイトはかなりサラっと探すだけで事足りるように思います。
不要なプログラムを拒否することで、ディスク領域が節約できるようです。
ちなみに power shell ファイルをスクリプトとして実行する場合には、以下のコマンドが必要です。
Set-ExecutionPolicy RemoteSigned
※僕の環境では Windows2008 R2 だったのですが、スクリプトが動作しませんでした。スペックが低いからなのか、タイムアウトになってしまいました。
インデックスの再作成
Re-index the WSUS 3.0 Database
WSUS DB インデックスの再構成の手順について
僕の環境では20分ぐらいで完了しました。
インデックスの再作成がどの程度効果があるのかは分かりませんが、長期間放置の場合には必要です。
クリーンアップウィザードの実行
WSUS メンテナンス ガイド
クリーンアップウィザードは必ず定期的に実行する必要があります。
結局そこそこのパフォーマンスのサーバーを用意しないと、サーバーが遅くてメンテナンスが手間なのでそこが難しいところだと思います。
検証で短期間利用したら、すぐに標準のMSからのダウンロードに変えてしまうのです。
とは言っても、メンテナンスも必要なので以下の通りです。
WSUS クリーンアップ ウィザードのタイムアウトが解決したよ
--- 上記から引用 ---
USE SUSDB ;
GO
EXEC sp_configure 'remote query timeout', 0 ;
GO
RECONFIGURE ;
GO
-----------------------
MMCで管理しているときに、すぐにタイムアウトになってしまうように感じました。上記コマンドでタイムアウトしないということです。が、それでもまだやっぱりエラーになっています。サーバーのスペックの問題なのでしょうが、うーーーん。
不要な更新プログラムは「拒否済み」に設定しよう！
上記ブログは若干文体が異なりますね。ノリが軽いような文章です。
しかし重要なことがかいてあります。WSUSはこのMSブログが結構しっかりしているので、個々をチェックすれば、海外サイトはかなりサラっと探すだけで事足りるように思います。
不要なプログラムを拒否することで、ディスク領域が節約できるようです。
ちなみに power shell ファイルをスクリプトとして実行する場合には、以下のコマンドが必要です。
Set-ExecutionPolicy RemoteSigned
※僕の環境では Windows2008 R2 だったのですが、スクリプトが動作しませんでした。スペックが低いからなのか、タイムアウトになってしまいました。
インデックスの再作成
Re-index the WSUS 3.0 Database
WSUS DB インデックスの再構成の手順について
僕の環境では20分ぐらいで完了しました。
インデックスの再作成がどの程度効果があるのかは分かりませんが、長期間放置の場合には必要です。
クリーンアップウィザードの実行
WSUS メンテナンス ガイド
クリーンアップウィザードは必ず定期的に実行する必要があります。
結局そこそこのパフォーマンスのサーバーを用意しないと、サーバーが遅くてメンテナンスが手間なのでそこが難しいところだと思います。
