前の記事の続き。 scoopを無事再インストールして再度nodejs,gitbook-cliをインストールしようとしてもやはりエラーが出る。最新の15,およびLTSの14でもだめ。 どうもこれは問題になっているらしく、10まで戻らないとダメ見たい… https://github.com/GitbookIO/gitbook-cli/issues/110 nvmでバージョンを10.23.0に指定してインストールしたところ、正常に動作することを確認できた
Windows10でscoopでのパッケージ管理にはまり、node.jsもscoop経由でインストールして利用した際にはまったこと。 Gitbookを実行しようとしたところ、なぜかうまくいかない。これがうまくいかない理由はscoopとは関係なかったので別記事で。 いったん環境を切りにしようと思い、nodejsをアンインストールしようとするとこける scoop uninstall nodejs scoop自体をアンインストールしようとしても同様。 scoop uninstall scoop エラーメッセージにて階層のかなり深いファイルにアクセスできないと表示されるので、エクスプローラーでファイルの存在は確認できる。が、ファイルを開こうとするとパスが長すぎるため開けない旨のエラーが出る。 どうも、nodeがネストされたフォルダにキャッシュ等を置こうとする仕様のために発生するようだ。 https://github.com/lukesampson/scoop/issues/737 Windows10では既定で260文字となっている https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file#maximum-path-length-limitation さしあたっては以下の記事にあるように、ネットワークドライブとして参照することで一時的にこの制限を回避できる http://office-qa.com/win/win187.htm 削除後、以下の記事にあるComputer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabledレジストリを1に変更して再起動後、症状は発生しなくなった https://docs.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation#enable-long-paths-in-windows-10-version-1607-and-later
各種バッチ処理の実行結果をメール通知するようにしています。 各サーバに直接見に行くよりはメールのほうが確認は楽なのですが、それでもメール件数が多いと大変で、リストを元に人手で確認すると漏れる可能性があることが心配でした。 そこで、メールに識別しやすいヘッダを懸命につけてGmailに飛ばし、Google Apps Scriptで識別子をもとに取得してGoogle Spreadsheetに結果を表示するようにしたところ、一気に楽になりました。 Spreadsheetの一覧をチェックして結果を通知するGoogle Apps Scriptも別途作成し、通知で何らかのエラーがあればSpreadsheetを見に行くようにしています。 手間はかかりましたがGoogle Apps Scriptの作成、トリガー登録は無料アカウントでもでき、claspというツールを使えばコードを手元で編集して簡単にアップできるので、ほかにも色々使えそうに思いました。
Dockerにて、本家のイメージを使って運用している。 4.0.22から4.0.24にアップしたところ、以下のエラーが出て監視画面が表示されなくなってしまった。 DateTime::__construct(): Invalid date.timezone value '"Asia/Tokyo"', we selected the timezone 'UTC' for now. よくよくみると、「Asia/Tokyo」の前後にダブルクォーテーションとシングルクォーテーションがついている。ひょっとしてと思い、Dockerで環境変数を指定している箇所 PHP_TZ="Asia/Tokyo" をダブルクォーテーションなしで PHP_TZ=Asia/Tokyo と修正したところ、無事表示されるようになった。
Active Directoryの情報をPowershellで取得し、管理資料に起こすスクリプトを作成。せっかくなので定期的にスクリプトを実行して差分がないかタスクスケジューラで定期実行してチェックする運用を構築していた時に問題が発生。 手動で実行する分には問題ないのだが、タスクスケジューラを通して実行するとなぜか以下問題が発生 ADのオブジェクトのSort-Objectでの並び替えが効かない Get-GPOReportで出力した一部XMLに差分が検知される。実際に比較してみると差分はないのだが… https://social.technet.microsoft.com/Forums/ja-JP/a7e363fa-4553-4468-b123-a1e971c68a78/12525124641245812501123751239012356124271251812540124701254012?forum=powershellja によると、手動実行とタスクスケジューラからの実行時で既定のモジュールパスが異なるということなので、それによるのかもしれない。が、プログラムがこけているわけではないので、原因はどれなのか得的できず、どれをロードすればよいのかわからない。 実行の都度生成されるファイルが変わってしまうようではチェックには使えないということで、タスクスケジューラによるチェックは断念した。 Powershellをタスクスケジューラから呼び出す処理はほかに多数書いており、問題になったことはない。Active Directoryを操作する際にはImport-Moduleで専用のモジュールを読み込んで処理をするのだが、こういった書き方をする場合に問題となるのかもしれない。 原因は不明。