memo.

カテゴリー: 技術系

  • Azure上でPythonを利用する場合のサポートバージョンのメモ

    Pythonとしての各バージョンとサポート期限は下記。概ね5年間のサポート。ただし、リリースされてからでないと、各種フレームワークなどが追随してこない。リリースされてから、開発等を始めるとすると、利用できる期間は4年間程度。開発会社によっては、常に最新のものを追いかけず、1つ前のバージョンをつかったりする可能性もあるので、もっと短くなる可能性もある。

    Pythonのリリースとサポート期限の一覧
    https://devguide.python.org/versions/

    Azure App Serviceの場合、Python 3.11のバージョンは指定できるが、Python 3.11.xのようなパッチバージョンまでは指定できない。サポートポリシーによると、Azure側でアップデートが行われる。言語のサポートが終了してもすぐに使えなくなるわけではなく、Azureのポリシーとしては「特定の言語のコミュニティ サポートが終了しても、アプリケーションは変更することなく引き続き実行できます。」とのこと。

    App Service 言語ランタイムのサポート ポリシー
    https://learn.microsoft.com/ja-jp/azure/app-service/language-support-policy

    Azure Functionsの場合は、ランタイムバージョン毎に、利用できる言語のバージョンが決まっている。そのため、利用したい言語のバージョンに合わせて、ランタイムバージョンを選択する必要がある。そして、言語側のサポートが終了すると、Azure Functionでも、サポートが終わる。

    Azure Functions でサポートされている言語
    https://learn.microsoft.com/ja-jp/azure/azure-functions/supported-languages

    Azure FunctionでのPythonのサポート状況と、サポート終了のお知らせ。
    https://azure.microsoft.com/ja-jp/updates/azure-functions-support-for-python-36-is-ending-on-30-september-2022/

  • ウェブ版のTeamsが「Teams を読み込んでいます」で止まる

    ウェブ版のTeamsで、ミーティングのURLをクリックして、ウェブ版を起動させると、高確率で「Teams を読み込んでいます」の表示（もしくは消えて白い画面）で止まってしまう。

    下記のマイクロソフトのトラブルシュートも試して、Cookieを受け入れるようにしたが、状況は変わらない。

    https://learn.microsoft.com/ja-jp/microsoftteams/troubleshoot/teams-sign-in/sign-in-loop

    Cookieのところでないとすると、打つ手はないので、「Teams を読み込んでいます」で止まった場合には、

    ブラウザでリロードして、Teamsのウェブアプリが正常に読み込まれるまで、リロードするしかなさそうだ。

    あとは、マイクロソフトがエラーが減るように対応してくれるまで待つしかない。対応してくれればだが。

  • Powershellで他のWindowsに接続するコマンドレット

    前提として、WinRMの設定が行われていて、リモート接続できること。Powershellを開いて、”Enter-PSSession” コマンドレットを実行することで、別のWindowsにPowershellで接続でき、コマンドレットやDOSコマンドを実行することができる。

    Enter-PSSession -ComputerName 接続先のホスト名やIPアドレス -Credential ログイン名

    接続できると、プロンプトのところに、接続先のホスト名が表示されるので、どこにつながっているのかがわる。

    接続を終了するときは、”Exit-PSSession”もしくは”exit” で抜ける。

    実行例。

    PS C:\Users\zen> Enter-PSSession -ComputerName Labo07 -Credential psadmin
PowerShell credential request
Enter your credentials.
Password for user psadmin: *********
[Labo07]: PS C:\Users\psadmin\Documents>
[Labo07]: PS C:\Users\psadmin\Documents> Exit-PSSession
PS C:\Users\zen>

  • FreeBSD 13.1から13.2へのバージョンアップ

    FreeBSD 13.1のサポートが終わるので、FreeBSD 13.2にバージョンアップした。コマンドは、下記で行った。

    freebsd-update fetch
freebsd-update install
freebsd-update upgrade -r 13.2-RELEASE
freebsd-update install
shutdown -r now
freebsd-update install
pkg-static upgrade -f

    前のFreeBSD 12.2から13.1へ上げたときと、コマンドは一緒。今回は、すんなりとバージョンアップされた。

  • Veeam Backupで容量不足でバックアップ失敗したときのメッセージ

    下記のようなメッセージで、Veeam Backup（Veeam Backup ＆ Replication 11）が失敗した。原因は、メッセージ通りで、バックアップ先のディスク（リポジトリ）の容量不足で、フルバックアップのvbkファイルが書き込めなかった。

    2023/07/08 2:23:12 :: Agent: Failed to process method {Transform.CompileFIB}: There is not enough space on the disk.
Failed to write data to the file [D:\VeeamBK\Backup_xxxxxx - xxxxxxD2023-07-08T014313_FD59.vbk].

  • GitLab CE で小まめにアップデートし忘れて、apt updateでエラーになった。

    すでに何度目かのミス。GitLab CEはアップデートのタイミングが早いので、小まめにアップデートを行っておかないと、アップグレードパスから外れて、apt updateでアップデートできなくなる。下記は、おきまりのエラー表示。

    dpkg: アーカイブ /var/cache/apt/archives/gitlab-ce_16.1.2-ce.0_amd64.deb の処理 中にエラーが発生しました (--unpack):
 new gitlab-ce package pre-installation script subprocess returned error exit status 1
処理中にエラーが発生しました:
 /var/cache/apt/archives/gitlab-ce_16.1.2-ce.0_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

    今回は、GitLab-ce-15.6.0から、最新のGitLab-ce-16.1.2なので、下記のアップグレードパスを踏んでアップグレードした。

    GitLab-ce-15.6.0
    ↓
    GitLab-ce-15.11.11 ・・・15系の最終バージョン
    ↓
    GitLab-ce-16.1.2

    コマンドは、次の順番で実行。これで、無事に16系の最新（作業時最新の16.1.2）にアップデートできた。

    sudo apt update
sudo apt upgrade gitlab-ce=15.11.11-ce.0
sudo apt upgrade gitlab-ce=16.1.2-ce.0
sudo gitlab-ctl restart

    GitLab CEのアップグレードパスについては、下記を参照。

    https://docs.gitlab.com/ee/update/index.html#upgrading-to-a-new-major-version

  • wbxcacheフォルダ

    Windowsのローカルディスク（Ｃドライブ）の容量が枯渇してきたので、調べたところ、「wbxcache」のフォルダが数GBの容量を使っていた。

    容量をたくさん使っていたwbxcacheのフォルダパス

    %USERPROFILE%\AppData\Local\WebEx\wbxcache

    このフォルダは、ウェブ会議ツールの、Cisco WebEXのキャッシュのフォルダだった。このフォルダの中は、キャッシュ情報だけとのこと。エクスプローラーで選択して、削除する。

    参考： https://help.webex.com/ja-jp/article/WBX9000035301/Windows-%E3%81%A7-Cisco-Webex-Meetings-%E3%81%AE%E3%82%AD%E3%83%A3%E3%83%83%E3%82%B7%E3%83%A5%E3%82%92%E6%B6%88%E5%8E%BB%E3%81%99%E3%82%8B%E3%81%AB%E3%81%AF%E3%81%A9%E3%81%86%E3%81%99%E3%82%8C%E3%81%B0%E3%82%88%E3%81%84%E3%81%A7%E3%81%99%E3%81%8B?

  • Windows11からWindows Server 2003上のSQL ServerにODBC接続できない。

    タイトルのままではあるが、Windows11からWindows Server 2003 R2上のSQL Server 2005にODBC接続できない。

    セキュリティの関係で接続できない。ODBCドライバのバージョンを古いものに変えてもできないので、OSレベルでのセキュリティの問題で接続できない。

  • ファームウェアバージョンにより、Smart Array P440ar Contoller で一時的にArrayが認識不能になる可能性がある。

    iLO4では、ログにSmart Array P440ar Contoller のエラーが出ているが、その後のステータスは正常になっている。

    HPEのサポートによると、Smart Array P440ar Contoller のファームウェアのバージョンにより、一時的に認識不能になることがあるとのこと。だが、ファームウェアのバージョンを変えたほうがよいか、という質問には十分ファームウェアバージョンは高いとのこと。

    iLO4上でのヘルスチェックが正常になっているのであれば、問題ないとのこと。

    どちらにしても、HPEサポートへの問い合わせは必須。

  • Veeam Backupの合成フルバックアップが便利

    Veeam Backup & Replication11（以降）の合成フルバックアップの機能が便利だ。毎週、フルバックアップの作成をしなくても、バックアップされているデータから、フルバックアップに相当するファイルが作成される。フルバックアップにかかる負荷が軽減されるので、結構、便利な機能だ。

    合成フルバックアップの説明については、下記のURLに載っている。

    https://helpcenter.veeam.com/jp/docs/backup/vsphere/synthetic_full_backup.html?ver=110

    合成フルバックアップには、次のような利点があります。

    合成フルバックアップは、既にディスクに保存されているバックアップファイルから作成されるため、ネットワークリソースを使用しません。

    合成フルバックアップはバックアップリポジトリに直接合成されるため、本番環境に対する負荷が軽減されます。

    合成フルバックアップの設定は下記。

    １．Veeam Backupのバックアップ設定のウィザードを開く

    ２．ウィザードを「Storage」に進める

    ３．「Advanced」のボタンをクリックする

    ４．「Create synthetic full backups periodically」オプションにチェックを入れて、OKをクリックする

    ５．他の設定を設定すれば終わり

    できれば、フルバックアップは月で採りたいのだが、現状では曜日しか選べないので週次での取得になってしまう。