Elastic Compute Service:パブリックイメージの既知の問題

問題の説明: centos_8_0_x64_20G_alibase_20200218.vhdパブリックイメージから作成されたインスタンスに接続すると、インスタンスのオペレーティングシステムバージョンがCentOS 8.1であることがわかります。

testuser@ecshost:~$ lsb_release -a
LSB Version:    :core-4.1-amd64:core-4.1-noarch
Distributor ID:    CentOS
Description:    CentOS Linux release 8.1.1911 (Core)
Release:    8.1.1911
Codename:    Core

原因: centos_8_0_x64_20G_alibase_20200218.vhdイメージは、最新のコミュニティ更新パッケージを使用して更新されたパブリックイメージです。 イメージ内のCentOSのバージョンが8.1にアップグレードされました。 したがって、実際のオペレーティングシステムのバージョンはCentOS 8.1です。

影響を受けるイメージ: centos_8_0_x64_20G_alibase_20200218.vhd。

解決策: RunInstances操作などのAPI操作を呼び出し、ImageIdパラメーターをcentos_8_0_x64_20G_alibase_20191225.vhdに設定して、オペレーティングシステムのバージョンがCentOS 8.0のインスタンスを作成できます。

問題の説明: 特定のCentOS 7パブリックイメージのIDが更新されました。これは、自動O&M中にイメージIDを取得するためのポリシーに影響を与える可能性があります。

影響を受ける画像: CentOS 7.5とCentOS 7.6。

原因: 最新バージョンのCentOS 7.5とCentOS 7.6のパブリックイメージで使用されているイメージIDは、%<OS type>%_%<Major version number>%_%<Minor version number >%_%<Special field>%_alibase_%<Date>%.%<Format>% です。 たとえば、CentOS 7.5パブリックイメージのイメージIDプレフィックスは、centos_7_05_64からcentos_7_5_x64に更新されます。 この場合、イメージIDの更新時に影響を受ける可能性のある自動O&Mポリシーを変更する必要があります。 イメージIDの詳細については、「2023のリリースノート」をご参照ください。

問題の説明: CentOS 7を実行する一部のインスタンスを初めて再起動すると、これらのインスタンスのホスト名が大文字から小文字に変わります。 次の表にいくつかの例を示します。

次のCentOSパブリックイメージおよびこれらのパブリックイメージから派生したカスタムイメージが影響を受けます。

• centos_7_2_64_40G_base_20170222.vhd

• centos_7_3_64_40G_base_20170322.vhd

• centos_7_03_64_40G_alibase_20170503.vhd

• centos_7_03_64_40G_alibase_20170523.vhd

• centos_7_03_64_40G_alibase_20170625.vhd

• centos_7_03_64_40G_alibase_20170710.vhd

• centos_7_02_64_20G_alibase_20170818.vhd

• centos_7_03_64_20G_alibase_20170818.vhd

• centos_7_04_64_20G_alibase_201701015.vhd

影響を受けるホスト名: インスタンスにデプロイされたアプリケーションのホスト名が大文字と小文字を区別する場合、これらのインスタンスを再起動するとサービスが影響を受ける可能性があります。 次の表に、インスタンスの再起動後にホスト名が変更されるかどうかを示します。

解決策: インスタンスの再起動後にインスタンスのホスト名に大文字を保持するには、次の操作を実行します。

1. インスタンスに接続します。

   詳細については、「ECSインスタンスへの接続方法」をご参照ください。

2. 既存のホスト名を表示します。

   [testuser@izbp193*****3i161uynzzx ~]# hostname
   izbp193*****3i161uynzzx

3. 次のコマンドを実行して、ホスト名を静的にします。

   hostnamectl set-hostname --static iZbp193*****3i161uynzzX

4. 次のコマンドを実行して、更新されたホスト名を表示します。

   [testuser@izbp193*****3i161uynzzx ~]# hostname
   iZbp193*****3i161uynzzX

影響を受けるカスタムイメージを使用する場合は、cloud-initを最新バージョンに更新してから、別のカスタムイメージを作成することをお勧めします。 この問題を防ぐには、新しいカスタムイメージを使用してインスタンスを作成します。 詳細については、「cloud-initのインストール」および「インスタンスからカスタムイメージを作成する」をご参照ください。

問題の説明: NFSクライアントがインストールされているCentOS 6.8インスタンスは応答せず、再起動する必要があります。

原因: オペレーティングシステムのカーネルバージョンが2.6.32-696から2.6.32-696.10の範囲のインスタンスでNFSサービスを使用すると、NFSクライアントは、通信遅延のために不具合が発生した場合にTCP接続を終了しようとします。 NFSサーバがNFS要求に応答するのが遅い場合、NFSクライアントによって開始された接続は、延長された時間期間にわたってFIN_WAIT2状態のままであり得る。 ほとんどの場合、接続はタイムアウトし、接続がFIN_WAIT2状態に入ってから1分後に閉じられます。 次いで、NFSクライアントは、新しい接続を開始することができる。 ただし、カーネルバージョン2.6.32-696から2.6.32-696.10には、TCP接続の確立に問題があります。 その結果、接続はFIN_WAIT2状態のままであり、NFSクライアントはTCP接続を回復することができず、新しいTCP接続を開始することができません。 これによりリクエストがフリーズし、問題を解決する唯一の方法はインスタンスを再起動することです。

影響を受ける画像: centos_6_08_32_40G_alibase_20170710.vhdとcentos_6_08_64_20G_alibase_20170824.vhd。

解決策: yum updateコマンドを実行して、カーネルを2.6.32-696.11以降に更新します。

問題の説明: Debian 9パブリックイメージから作成されたクラシックネットワークのインスタンスはpingできません。

原因: デフォルトでは、systemd-networkdサービスはDebian 9で無効になっています。 Debian 9パブリックイメージから作成されたクラシックネットワークのインスタンスには、動的ホスト構成プロトコル (DHCP) を使用してIPアドレスを自動的に割り当てることはできません。

影響を受けるイメージ: debian_9_06_64_20G_alibase_20181212.vhd。

解決策: 次のコマンドを順番に実行します。

systemctl enable systemd-networkd 

systemctl start systemd-networkd

問題の説明: Fedora CoreOSイメージを使用してインスタンスaを作成した後、インスタンスAからFedora CoreOSカスタムイメージを作成し、そのカスタムイメージを使用してインスタンスBを作成します。

たとえば、Fedora CoreOSオペレーティングシステムを実行するインスタンスaからFedora CoreOSカスタムイメージを作成し、インスタンスAのホスト名をtest001に設定します。 次に、カスタムイメージからインスタンスBを作成し、インスタンスBのホスト名をtest002に設定します。 インスタンスBが作成されて接続された後、インスタンスBのホスト名はtest001のままです。

原因: Alibaba Cloudが提供するFedora CoreOSパブリックイメージは、Fedora CoreOSが提供するIgnitionを使用してインスタンス設定を初期化します。 Ignitionは、Fedora CoreOSおよびRHEL CoreOSが起動時にinitramfsのディスクを管理するために使用するユーティリティです。 Fedora CoreOSインスタンスが初めて起動すると、ignitionのcoreos-Ignition-firstboot-complete.serviceが /boot/ignition.firstbootファイルが存在するかどうかを確認し、インスタンス設定を初期化するかどうかを決定します。 /boot/ignition.firstbootファイルが存在する場合、システムはインスタンス設定 (ホスト名設定を含む) を初期化し、/boot/ignition.firstbootファイルを削除します。

Fedora CoreOSインスタンスは、Fedora CoreOSカスタムイメージの作成に使用される前に、少なくとも1回起動されている必要があります。 インスタンスが初めて起動すると、インスタンスのイメージから /boot/ignition.firstbootファイルが削除されます。 したがって、インスタンスから作成されたFedora CoreOSカスタムイメージには、/boot/ignition.firstbootファイルは含まれません。 Fedora CoreOSカスタムイメージから初めて作成されたインスタンスが起動すると、システムはインスタンス設定を初期化しません。 この場合、インスタンスのホスト名は変更されません。

解決策：

Fedora CoreOSインスタンスを使用してカスタムイメージを作成する前に、root権限 (管理者権限) を使用して、/bootディレクトリに /ignition.firstbootファイルを作成します。 次の操作を実行します。

1. 次のコマンドを実行して、読み取り /書き込みモードで /bootを再マウントします。

   sudo mount /boot -o rw,remount

2. 次のコマンドを実行して、/ignition.firstbootファイルを作成します。

   sudo touch /boot/ignition.firstboot

3. 次のコマンドを実行して、読み取り専用モードで /bootを再マウントします。

   sudo mount /boot -o ro,remount

イグニッションの設定方法については、「プロビジョニング後にイグニッションを0600および削除する権限の変更 /ブート /イグニッション /config.ign」をご参照ください。

問題の説明: openSUSEカーネルバージョンが4.12.14-lp151.28.52-defaultに更新されると、特定のCPUタイプを持つインスタンスが起動中にフリーズする可能性があります。 既知のCPUタイプはIntel®Xeon®CPU E5-2682 v4 @ 2.50GHz。 コールトレースのデバッグ結果を次に示します。

[    0.901281] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    0.901281] CR2: ffffc90000d68000 CR3: 000000000200a001 CR4: 00000000003606e0
[    0.901281] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[    0.901281] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[    0.901281] Call Trace:
[    0.901281]  cpuidle_enter_state+0x6f/0x2e0
[    0.901281]  do_idle+0x183/0x1e0
[    0.901281]  cpu_startup_entry+0x5d/0x60
[    0.901281]  start_secondary+0x1b0/0x200
[    0.901281]  secondary_startup_64+0xa5/0xb0
[    0.901281] Code: 6c 01 00 0f ae 38 0f ae f0 0f 1f 84 00 00 00 00 00 0f 1f 84 00 00 00 00 00 90 31 d2 65 48 8b 34 25 40 6c 01 00 48 89 d1 48 89 f0 <0f> 01 c8 0f 1f 84 00 00 00 00 00 0f 1f 84 00 00 00 00 00 ** **

原因: 新しいカーネルバージョンがCPUマイクロコードと互換性がありません。 詳細については、「起動中のフリーズの問題」をご参照ください。

影響を受けるイメージ: opensuse_15_1_x64_20G_alibase_20200520.vhd。

解決策: /boot/grub2/grub.cfgファイルで、linuxで始まる行にidleカーネルパラメーターを追加し、このパラメーターをnomwaitに設定します。 次の例は、ファイルを変更する方法を示しています。

menuentry 'openSUSE Leap 15.1'  --class opensuse --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-20f5f35a-fbab-4c9c-8532-bb6c66ce****' {
        load_video
        set gfxpayload=keep
        insmod gzio
        insmod part_msdos
        insmod ext2
        set root='hd0,msdos1'
        if [ x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root --hint='hd0,msdos1'  20f5f35a-fbab-4c9c-8532-bb6c66ce****
        else
          search --no-floppy --fs-uuid --set=root 20f5f35a-fbab-4c9c-8532-bb6c66ce****
        fi
        echo    'Loading Linux 4.12.14-lp151.28.52-default ...'
        linux   /boot/vmlinuz-4.12.14-lp151.28.52-default root=UUID=20f5f35a-fbab-4c9c-8532-bb6c66ce****  net.ifnames=0 console=tty0 console=ttyS0,115200n8 splash=silent mitigations=auto quiet idle=nomwait
        echo    'Loading initial ramdisk ...'
        initrd  /boot/initrd-4.12.14-lp151.28.52-default
}

問題の説明: RHEL 8 64ビットオペレーティングシステムを実行しているECSインスタンスでyum updateコマンドを実行してカーネルバージョンを更新した後、インスタンスを再起動してもインスタンスオペレーティングシステムのカーネルバージョンは変更されません。

原因: RHEL 8 64ビットオペレーティングシステムでは、grub2環境変数を格納する /boot /GRUB2 /grubenvファイルのサイズが1,024バイトではありません。 その結果、カーネルのバージョンを更新することはできません。

解決策: カーネルバージョンを更新した後、新しいカーネルバージョンをデフォルトの起動バージョンに設定します。 次の操作を実行します。

1. 次のコマンドを実行して、カーネルのバージョンを更新します。

   yum update kernel -y

2. 次のコマンドを実行して、オペレーティングシステムのカーネル起動パラメーターを取得します。

   grub2-editenv list | grep kernelopts

3. 次のコマンドを実行して、古い /grubenvファイルをバックアップします。

   mv /boot/grub2/grubenv /home/grubenv.bak

4. 次のコマンドを実行して、/grubenvファイルを作成します。

   grub2-editenv /boot/grub2/grubenv create

5. 次のコマンドを実行して、新しいカーネルバージョンをデフォルトの起動バージョンに設定します。

   この例では、新しいカーネルバージョンは /boot/vmlinuz-4.18.0-305.19.1.el8_4.x86_64です。

   grubby --set-default /boot/vmlinuz-4.18.0-305.19.1.el8_4.x86_64

6. 次のコマンドを実行して、カーネル起動パラメーターを設定します。

   この例では、- set kerneloptsコマンドを実行して、手順iiで取得したカーネル起動パラメーターの値をkerneloptsの値に設定します。

   grub2-editenv - set kernelopts="root=UUID=0dd6268d-9bde-40e1-b010-0d3574b4**** ro crashkernel=auto net.ifnames=0 vga=792 console=tty0 console=ttyS0,115200n8 noibrs nosmt"

7. 次のコマンドを実行して、新しいカーネルバージョンを有効にするためにインスタンスを再起動します。

   reboot

   警告

   再起動操作により、インスタンスが短時間停止し、インスタンスで実行されているサービスが中断される可能性があります。 オフピーク時にインスタンスを再起動することを推奨します。

問題の説明: 有料のAlibaba CloudイメージをSUSE Linux Enterprise ServerまたはSUSE Linux Enterprise Server for SAPで使用すると、同時マルチスレッド (SMT) サーバーで接続タイムアウトなどの接続エラーが発生することがあります。 SMTサーバーのコンポーネントをダウンロードまたは更新すると、次のようなエラーメッセージが返されます。

• 登録サーバーから「このサーバーはこのサービスへのアクセスが許可されていることを確認できませんでした」 (500)

• サービス 'SMT-http_mirrors_cloud_aliyuncs_com 'ロケーションのリポジトリインデックスファイルの取得に関する問題 ****

影響を受けるイメージ: SUSE Linux Enterprise ServerおよびSUSE Linux Enterprise Server for SAP

解決策: SMTを再度登録して有効にします。

1. 次のコマンドを順番に実行して、SMTを登録して有効にします。

   SUSEConnect -d
   SUSEConnect --cleanup
   systemctl restart guestregister

2. 次のコマンドを実行して、SMTが有効かどうかを確認します。

   SUSEConnect -s

   SMTを有効にすると、次のようなコマンド出力が返されます。

   [{"identifier":"SLES_SAP","version":"12.5","arch":"x86_64","status":"Registered"}]

問題の説明: 以前のカーネルバージョンがSLES 12 SP5に更新された場合、またはSLES 12 SP5のカーネルを更新した場合、特定のCPUタイプを持つインスタンスが起動中にフリーズすることがあります。 これらの既知のCPUタイプはIntel ®Xeon®CPU E5-2682 v4 @ 2.50GHzとインテル®Xeon®CPU E7-8880 v4 @ 2.20GHz。 コールトレースのデバッグ結果を次に示します。

[    0.901281] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    0.901281] CR2: ffffc90000d68000 CR3: 000000000200a001 CR4: 00000000003606e0
[    0.901281] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[    0.901281] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[    0.901281] Call Trace:
[    0.901281]  cpuidle_enter_state+0x6f/0x2e0
[    0.901281]  do_idle+0x183/0x1e0
[    0.901281]  cpu_startup_entry+0x5d/0x60
[    0.901281]  start_secondary+0x1b0/0x200
[    0.901281]  secondary_startup_64+0xa5/0xb0
[    0.901281] Code: 6c 01 00 0f ae 38 0f ae f0 0f 1f 84 00 00 00 00 00 0f 1f 84 00 00 00 00 00 90 31 d2 65 48 8b 34 25 40 6c 01 00 48 89 d1 48 89 f0 <0f> 01 c8 0f 1f 84 00 00 00 00 00 0f 1f 84 00 00 00 00 00 ** **

原因: 新しいカーネルバージョンがCPUマイクロコードと互換性がありません。

解決策: /boot/grub2/grub.cfgファイルで、linuxで始まる行にidleカーネルパラメーターを追加し、このパラメーターをnomwaitに設定します。 次の例は、ファイルを変更する方法を示しています。

menuentry 'SLES 12-SP5'  --class sles --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-fd7bda55-42d3-4fe9-a2b0-45efdced****' {
        load_video
        set gfxpayload=keep
        insmod gzio
        insmod part_msdos
        insmod ext2
        set root='hd0,msdos1'
        if [ x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root --hint='hd0,msdos1'  fd7bda55-42d3-4fe9-a2b0-45efdced****
        else
          search --no-floppy --fs-uuid --set=root fd7bda55-42d3-4fe9-a2b0-45efdced****
        fi
        echo    'Loading Linux 4.12.14-122.26-default ...'
        linux   /boot/vmlinuz-4.12.14-122.26-default root=UUID=fd7bda55-42d3-4fe9-a2b0-45efdced****  net.ifnames=0 console=tty0 console=ttyS0,115200n8 mitigations=auto splash=silent quiet showopts idle=nomwait
        echo    'Loading initial ramdisk ...'
        initrd  /boot/initrd-4.12.14-122.26-default
}

問題の説明: ecs.i2.4xlargeなどの特定のインスタンスタイプのインスタンスが、カーネルバージョンが4.18.0-240.1.1.el8_3.x86_64のRed Hat Enterprise Linux (RHEL) 8.3やCentOS 8.3などの最新のカーネルバージョンのオペレーティングシステムを実行している場合、インスタンスの起動時にコールトレースが発生する可能性があります。 コールトレースの例:

Dec 28 17:43:45 localhost SELinux:  Initializing.
Dec 28 17:43:45 localhost kernel: Dentry cache hash table entries: 8388608 (order: 14, 67108864 bytes)
Dec 28 17:43:45 localhost kernel: Inode-cache hash table entries: 4194304 (order: 13, 33554432 bytes)
Dec 28 17:43:45 localhost kernel: Mount-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Dec 28 17:43:45 localhost kernel: Mountpoint-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Dec 28 17:43:45 localhost kernel: unchecked MSR access error: WRMSR to 0x3a (tried to write 0x000000000000****) at rIP: 0xffffffff8f26**** (native_write_msr+0x4/0x20)
Dec 28 17:43:45 localhost kernel: Call Trace:
Dec 28 17:43:45 localhost kernel:  init_ia32_feat_ctl+0x73/0x28b
Dec 28 17:43:45 localhost kernel:  init_intel+0xdf/0x400
Dec 28 17:43:45 localhost kernel:  identify_cpu+0x1f1/0x510
Dec 28 17:43:45 localhost kernel:  identify_boot_cpu+0xc/0x77
Dec 28 17:43:45 localhost kernel:  check_bugs+0x28/0xa9a
Dec 28 17:43:45 localhost kernel:  ?  __slab_alloc+0x29/0x30
Dec 28 17:43:45 localhost kernel:  ?  kmem_cache_alloc+0x1aa/0x1b0
Dec 28 17:43:45 localhost kernel:  start_kernel+0x4fa/0x53e
Dec 28 17:43:45 localhost kernel:  secondary_startup_64+0xb7/0xc0
Dec 28 17:43:45 localhost kernel: Last level iTLB entries: 4KB 64, 2MB 8, 4MB 8
Dec 28 17:43:45 localhost kernel: Last level dTLB entries: 4KB 64, 2MB 0, 4MB 0, 1GB 4
Dec 28 17:43:45 localhost kernel: FEATURE SPEC_CTRL Present
Dec 28 17:43:45 localhost kernel: FEATURE IBPB_SUPPORT Present

原因: 最新のコミュニティ更新プログラムパッケージを使用して、モデル固有レジスタ (MSR) への書き込み用のパッチを含めることで、カーネルバージョンが更新されます。 ただし、ecs.i2.4xlargeなどの一部のインスタンスタイプは、仮想化による制限のため、MSRへの書き込みをサポートしていません。

解決策: コールトレースはシステムの動作や安定性に影響しません。 この問題は無視できます。

問題の説明: CentOS 8、SUSE Linux Enterprise Server (SLES) 15 SP2、openSUSE 15.2などの一部のオープンソースLinuxディストリビューションのカーネルがhfg6インスタンスで最新バージョンに更新されると、カーネルパニックエラーが発生する可能性があります。 トレース呼び出しのデバッグ方法の例を次の図に示します。

原因: 一部のLinuxカーネルバージョンは、クロック速度の高いhfg6汎用インスタンスファミリーと互換性がありません。

解決策：

• 互換性の問題は、SLES 15 SP2およびopenSUSE 15.2の最新のカーネルバージョンで修正されています。 次のコードは、変更コミットの情報を示しています。 最新のカーネルバージョンにこの情報が含まれている場合、カーネルバージョンはhfg6インスタンスファミリーと互換性があります。

  commit 1e33d5975b49472e286bd7002ad0f689af33fab8
  Author: Giovanni Gherdovich <ggherdovich@suse.cz>
  Date:   Thu Sep 24 16:51:09 2020 +0200
  
      x86, sched: Bail out of frequency invariance if
      turbo_freq/base_freq gives 0 (bsc#1176925).
  
      suse-commit: a66109f44265ff3f3278fb34646152bc2b3224a5
      
      
  commit dafb858aa4c0e6b0ce6a7ebec5e206f4b3cfc11c
  Author: Giovanni Gherdovich <ggherdovich@suse.cz>
  Date:   Thu Sep 24 16:16:50 2020 +0200
  
      x86, sched: Bail out of frequency invariance if turbo frequency
      is unknown (bsc#1176925).
  
      suse-commit: 53cd83ab2b10e7a524cb5a287cd61f38ce06aab7
  
  commit 22d60a7b159c7851c33c45ada126be8139d68b87
  Author: Giovanni Gherdovich <ggherdovich@suse.cz>
  Date:   Thu Sep 24 16:10:30 2020 +0200
  
      x86, sched: check for counters overflow in frequency invariant
      accounting (bsc#1176925).

• yum updateコマンドを実行して、hfg6インスタンスでCentOS 8のカーネルをkernel-4.18.0-240以降に更新すると、カーネルパニックエラーが発生することがあります。 このエラーが発生した場合は、カーネルを以前のバージョンにロールバックします。

問題の説明: Pipリクエストが時間切れまたは失敗することがあります。

影響を受けるイメージ: CentOS、Debian、Ubuntu、SUSE、openSUSE、Alibaba Cloud Linux。

原因: Alibaba Cloudは3つのpipリポジトリアドレスを提供します。 デフォルトのアドレスiがs mirrors.aliyun.comされます。 このアドレスにアクセスするには、インスタンスがインターネットにアクセスできる必要があります。 インスタンスにパブリックIPアドレスが割り当てられていない場合、pipリクエストはタイムアウトします。

• デフォルトのパブリックリポジトリアドレス: mirrors.aliyun.com

• 仮想プライベートクラウド (VPC) の内部リポジトリアドレス: mirrors.cloud.aliyuncs.com

• クラシックネットワークの内部リポジトリアドレス: mirrors.aliyuncs.com

解決策: 次のいずれかの方法を使用して問題を解決します。

• 方法 1

  elastic IPアドレス (EIP) をインスタンスに関連付けます。 詳細については、「EIPとECSインスタンスの関連付け」をご参照ください。

  インスタンス設定を変更するときに、サブスクリプションインスタンスにパブリックIPアドレスを再割り当てすることもできます。 詳細については、「サブスクリプションインスタンスのインスタンスタイプのアップグレード」をご参照ください。

• 方法 2

  pipリクエストが失敗した場合は、インスタンスでfix_pypi.shスクリプトを実行し、pip操作を再試行します。 以下の手順を実行します。

  1. インスタンスに接続します。

     詳細については、「VNCを使用したインスタンスへの接続」をご参照ください。

  2. 次のコマンドを実行して、スクリプトファイルを取得します。

     wget http://image-offline.oss-cn-hangzhou.aliyuncs.com/fix/fix_pypi.sh

  3. インスタンスのネットワークタイプに基づいて、次のいずれかのスクリプトを実行します。

     • インスタンスがVPCにある場合は、bash fix_pypi.sh "mirrors.cloud.aliyuncs.com" スクリプトを実行します。

     • インスタンスがクラシックネットワークにある場合は、bash fix_pypi.sh "mirrors.aliyuncs.com" スクリプトを実行します。

  4. pip操作を再試行します。

  次のサンプルコードでは、fix_pypi.shスクリプトについて説明します。

  #!/bin/bash
  
  function config_pip() {
      pypi_source=$1
  
      if [[ !  -f ~/.pydistutils.cfg ]]; then
  cat > ~/.pydistutils.cfg << EOF
  [easy_install]
  index-url=http://$pypi_source/pypi/simple/
  EOF
      else
          sed -i "s#index-url.*#index-url=http://$pypi_source/pypi/simple/#" ~/.pydistutils.cfg
      fi
  
      if [[ !  -f ~/.pip/pip.conf ]]; then
      mkdir -p ~/.pip
  cat > ~/.pip/pip.conf << EOF
  [global]
  index-url=http://$pypi_source/pypi/simple/
  [install]
  trusted-host=$pypi_source
  EOF
      else
          sed -i "s#index-url.*#index-url=http://$pypi_source/pypi/simple/#" ~/.pip/pip.conf
          sed -i "s#trusted-host.*#trusted-host=$pypi_source#" ~/.pip/pip.conf
      fi
  }
  
  config_pip $1