Elastic Compute Service:Masalah yang diketahui pada gambar publik

Deskripsi masalah: Setelah terhubung ke instans yang dibuat dari gambar publik centos_8_0_x64_20G_alibase_20200218.vhd, Anda menemukan bahwa versi sistem operasi instans tersebut adalah 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

Penyebab: Gambar tersebut tersedia dalam daftar gambar publik dan telah diperbarui dengan paket pembaruan komunitas terbaru. Versinya juga telah ditingkatkan ke 8.1. Oleh karena itu, versi aktualnya adalah 8.1.

ID gambar yang terpengaruh: centos_8_0_x64_20G_alibase_20200218.vhd.

Solusi: Untuk menggunakan CentOS 8.0, Anda dapat memanggil operasi API, seperti RunInstances, dan atur ImageId=centos_8_0_x64_20G_alibase_20191225.vhd untuk membuat instans ECS.

Deskripsi masalah: ID gambar publik CentOS 7 tertentu telah diperbarui. Hal ini dapat memengaruhi kebijakan untuk memperoleh ID gambar selama O&M otomatis.

Gambar yang terpengaruh: CentOS 7.5 dan CentOS 7.6

Penyebab: ID gambar yang digunakan oleh versi terbaru gambar publik CentOS 7.5 dan CentOS 7.6 memiliki format berikut: %OS type%_%Major version%_%Minor version%_%Special field%_alibase_%Date%.%Format%. Sebagai contoh, awalan ID gambar CentOS 7.5 diperbarui dari centos_7_05_64 menjadi centos_7_5_x64. Anda harus menyesuaikan kebijakan O&M otomatis apa pun yang mungkin terpengaruh oleh perubahan ID gambar tersebut. Untuk informasi lebih lanjut tentang ID gambar, lihat Catatan rilis untuk 2023.

Deskripsi masalah: Saat pertama kali beberapa instans yang menjalankan CentOS 7 direstart, hostname-nya berubah dari huruf kapital menjadi huruf kecil. Tabel berikut menjelaskan beberapa contohnya.

Gambar yang terpengaruh: Gambar publik CentOS berikut dan gambar kustom apa pun yang dibuat darinya.

• 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

Jenis hostname yang terpengaruh: Jika aplikasi Anda sensitif terhadap huruf besar/kecil pada hostname, bisnis Anda mungkin terpengaruh setelah Anda me-restart instans. Anda dapat menggunakan solusi berikut untuk memperbaiki jenis hostname ini.

Solusi: Untuk mempertahankan hostname dengan huruf kapital setelah me-restart instans, lakukan langkah-langkah berikut.

1. Terhubung ke instans.

   Untuk informasi lebih lanjut, lihat Pilih alat koneksi.

2. Lihat hostname saat ini.

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

3. Jalankan perintah berikut untuk menyimpan hostname secara permanen.

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

4. Jalankan perintah berikut untuk melihat hostname yang telah diperbarui.

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

Langkah selanjutnya: Jika Anda menggunakan gambar kustom, perbarui perangkat lunak cloud-init ke versi terbaru, lalu buat gambar kustom lainnya. Hal ini mencegah masalah yang sama terjadi saat Anda menggunakan gambar kustom bermasalah tersebut untuk membuat instans baru. Untuk informasi lebih lanjut, lihat Instal cloud-init dan Buat gambar kustom dari instans.

Deskripsi masalah: Instans CentOS 6.8 dengan klien NFS yang dimuat memasuki status wait yang diperpanjang. Masalah ini hanya dapat diatasi dengan me-restart instans.

Penyebab: Saat menggunakan layanan NFS pada versi kernel dari 2.6.32-696 hingga 2.6.32-696.10, nfsclient kernel secara proaktif memutus koneksi TCP jika terjadi gangguan latensi komunikasi (pulsa elektronik). Jika server NFS merespons lambat, koneksi yang dimulai oleh nfsclient dapat tersangkut dalam status FIN_WAIT2. Biasanya, koneksi dalam status FIN_WAIT2 akan timeout dan diklaim kembali setelah satu menit secara default, dan nfsclient dapat memulai kembali koneksi. Namun, karena cacat dalam implementasi TCP pada versi kernel tersebut, koneksi dalam status FIN_WAIT2 tidak pernah timeout. Akibatnya, koneksi TCP nfsclient tidak pernah dapat ditutup, koneksi baru tidak dapat dimulai, dan permintaan pengguna hang serta tidak dapat dipulihkan. Satu-satunya cara untuk memperbaiki ini adalah me-restart instans ECS.

ID gambar yang terpengaruh: centos_6_08_32_40G_alibase_20170710.vhd dan centos_6_08_64_20G_alibase_20170824.vhd.

Solusi: Anda dapat menjalankan perintah yum update untuk meningkatkan kernel sistem ke versi 2.6.32-696.11 atau lebih baru.

Deskripsi masalah: Instans tipe jaringan klasik yang dibuat dari gambar publik Debian 9 tidak dapat diping.

Penyebab: Layanan systemd-networkd dinonaktifkan secara default di sistem Debian. Instans tipe jaringan klasik tidak dapat diberi alamat IP secara otomatis dalam mode Dynamic Host Configuration Protocol (DHCP).

ID gambar yang terpengaruh: debian_9_06_64_20G_alibase_20181212.vhd.

Solusi: Anda harus menjalankan perintah berikut secara berurutan untuk mengatasi masalah ini.

systemctl enable systemd-networkd 

systemctl start systemd-networkd

Deskripsi masalah: Anda memilih gambar Fedora CoreOS untuk membuat instans ECS A, membuat gambar kustom dari instans A, lalu menggunakan gambar kustom tersebut untuk membuat instans ECS B baru. Hostname yang Anda atur untuk instans B tidak berlaku. Saat Anda login ke instans B untuk memeriksa, hostname instans B sama dengan hostname instans A.

Sebagai contoh, Anda memiliki instans ECS Fedora CoreOS (Instans A) dengan hostname test001. Anda kemudian menggunakan gambar kustom instans ini untuk membuat instans ECS baru (Instans B) dan mengatur hostname Instans B menjadi test002 saat pembuatan instans. Setelah Anda berhasil membuat dan terhubung jarak jauh ke Instans B, hostname Instans B tetap test001.

Penyebab: Gambar Fedora CoreOS yang disediakan sebagai gambar publik Alibaba Cloud menggunakan layanan Ignition resmi sistem operasi untuk inisialisasi instans. Layanan Ignition adalah program yang digunakan oleh Fedora CoreOS dan Red Hat Enterprise Linux CoreOS untuk mengoperasikan disk dalam initramfs selama startup sistem. Saat instans ECS pertama kali dimulai, coreos-ignition-firstboot-complete.service dalam Ignition memeriksa keberadaan file /boot/ignition.firstboot, yaitu file kosong, untuk menentukan apakah akan menginisialisasi instans. Jika file tersebut ada, instans diinisialisasi, termasuk mengonfigurasi hostname, dan file /boot/ignition.firstboot dihapus.

Karena instans Fedora CoreOS telah dijalankan setidaknya sekali setelah pembuatan, file /boot/ignition.firstboot dalam gambar kustom terkait telah dihapus. Saat Anda menggunakan gambar kustom ini untuk membuat instans ECS baru, instans tersebut tidak diinisialisasi pada startup pertamanya, dan hostname tidak berubah.

Solusi:

Sebelum membuat gambar kustom dari instans Fedora CoreOS, gunakan izin root (administrator) untuk membuat file /ignition.firstboot dalam direktori /boot. Operasi command-line-nya adalah sebagai berikut:

1. Mount ulang /boot dalam mode read-write.

   sudo mount /boot -o rw,remount

2. Buat file /ignition.firstboot.

   sudo touch /boot/ignition.firstboot

3. Mount ulang /boot dalam mode read-only.

   sudo mount /boot -o ro,remount

Untuk informasi lebih lanjut tentang konfigurasi Ignition, lihat Referensi konfigurasi Ignition.

Deskripsi masalah: Setelah kernel OpenSUSE ditingkatkan ke versi 4.12.14-lp151.28.52-default, instans dapat hang saat startup pada jenis CPU tertentu. Jenis CPU yang diketahui adalah Intel® Xeon® CPU E5-2682 v4 @ 2.50GHz. Hasil debugging call trace yang sesuai adalah sebagai berikut:

[    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 ** **

Penyebab: Versi kernel baru tidak kompatibel dengan Microcode CPU. Untuk informasi lebih lanjut, lihat Masalah hang saat startup.

Gambar yang terpengaruh: opensuse_15_1_x64_20G_alibase_20200520.vhd.

Solusi: Dalam file /boot/grub2/grub.cfg, tambahkan parameter kernel idle=nomwait pada baris yang dimulai dengan linux. Contoh berikut menunjukkan konten file yang telah dimodifikasi:

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
}

Deskripsi masalah: Di instans ECS yang menjalankan sistem operasi Red Hat Enterprise Linux 8 64-bit, Anda menjalankan perintah yum update untuk memperbarui versi kernel dan me-restart instans. Anda menemukan bahwa versi kernel tetap versi lama.

Penyebab: Di sistem operasi RHEL 8 64-bit, ukuran file /boot/grub2/grubenv yang menyimpan variabel lingkungan GRand Unified Bootloader (GRUB) 2 tidak normal. Ukuran file tersebut bukan 1.024 byte standar, yang menyebabkan pembaruan versi kernel gagal.

Solusi: Setelah memperbarui versi kernel, Anda perlu mengatur versi kernel baru sebagai versi startup default. Operasi lengkapnya adalah sebagai berikut:

1. Jalankan perintah berikut untuk memperbarui versi kernel.

   yum update kernel -y

2. Jalankan perintah berikut untuk mendapatkan parameter startup kernel dari sistem operasi saat ini.

   grub2-editenv list | grep kernelopts

3. Jalankan perintah berikut untuk mencadangkan file /grubenv lama.

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

4. Jalankan perintah berikut untuk menghasilkan file /grubenv baru.

   grub2-editenv /boot/grub2/grubenv create

5. Jalankan perintah berikut untuk mengatur versi kernel baru sebagai versi startup default.

   Dalam contoh ini, versi kernel baru yang diperbarui adalah /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. Jalankan perintah berikut untuk mengatur parameter startup kernel.

   Parameter - set kernelopts harus diatur secara manual ke nilai parameter startup kernel sistem operasi saat ini yang Anda peroleh pada langkah 2.

   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. Jalankan perintah berikut untuk me-restart instans ECS ke versi kernel baru.

   reboot

   Peringatan

   Operasi restart menghentikan instans untuk waktu singkat dan dapat mengganggu layanan yang sedang berjalan di instans. Kami menyarankan Anda me-restart instans selama jam sepi.

Deskripsi masalah: Saat Anda membeli dan menggunakan gambar berbayar Alibaba Cloud untuk SUSE Linux Enterprise Server atau SUSE Linux Enterprise Server for SAP, SMT Server mungkin timeout atau mengalami pengecualian. Saat Anda mencoba mengunduh atau memperbarui komponen, pesan error serupa berikut dikembalikan:

• Registration server returned 'This server could not verify that you are authorized to access this service.' (500)

• Problem retrieving the respository index file for service 'SMT-http_mirrors_cloud_aliyuncs_com' location ****

Gambar yang terpengaruh: SUSE Linux Enterprise Server dan SUSE Linux Enterprise Server for SAP

Solusi: Anda perlu mendaftar ulang dan mengaktifkan layanan SMT.

1. Jalankan perintah berikut secara berurutan untuk mendaftar ulang dan mengaktifkan layanan SMT.

   SUSEConnect -d
   SUSEConnect --cleanup
   systemctl restart guestregister

2. Jalankan perintah berikut untuk memverifikasi status aktivasi layanan SMT.

   SUSEConnect -s

   Jika output perintah serupa berikut dikembalikan, layanan SMT berhasil diaktifkan.

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

Deskripsi masalah: Setelah versi kernel sebelum SUSE Linux Enterprise Server (SLES) 12 SP5 ditingkatkan ke SLES 12 SP5, atau setelah versi kernel internal SLES 12 SP5 ditingkatkan, instans dapat hang saat startup pada jenis CPU tertentu. Jenis CPU yang diketahui adalah Intel® Xeon® CPU E5-2682 v4 @ 2.50GHz dan Intel® Xeon® CPU E7-8880 v4 @ 2.20GHz. Hasil debugging call trace yang sesuai adalah sebagai berikut:

[    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 ** **

Penyebab: Versi kernel baru tidak kompatibel dengan Microcode CPU.

Solusi: Dalam file /boot/grub2/grub.cfg, tambahkan parameter kernel idle=nomwait pada baris yang dimulai dengan linux. Contoh berikut menunjukkan konten file yang telah dimodifikasi:

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
}

Deskripsi masalah: Call trace seperti yang ditunjukkan di bawah dapat terjadi saat Anda memulai instans dari tipe instans tertentu (misalnya, ecs.i2.4xlarge) yang menjalankan sistem dengan kernel versi tinggi (misalnya, RHEL 8.3 atau CentOS 8.3 dengan versi kernel 4.18.0-240.1.1.el8_3.x86_64):

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

Penyebab: Pembaruan komunitas untuk versi kernel ini mencakup patch yang mencoba menulis ke Model-Specific Registers (MSR). Namun, beberapa tipe instans, seperti ecs.i2.4xlarge, tidak mendukung penulisan ke MSR karena versi virtualisasinya, yang menyebabkan call trace ini.

Solusi: Call trace ini tidak memengaruhi penggunaan normal atau stabilitas sistem. Anda dapat mengabaikan error ini.

Deskripsi masalah: Untuk beberapa sistem di komunitas Linux, seperti CentOS 8, SUSE Linux Enterprise Server 15 SP2, dan OpenSUSE 15.2, peningkatan ke versi kernel baru dalam instans dari keluarga instans tujuan umum frekuensi tinggi hfg6 dapat menyebabkan kernel panic. Contoh debugging call trace adalah sebagai berikut:

Penyebab: Terdapat masalah kompatibilitas antara keluarga instans tujuan umum frekuensi tinggi hfg6 dan beberapa versi kernel Linux.

Solusi:

• Versi kernel terbaru SUSE Linux Enterprise Server 15 SP2 dan OpenSUSE 15.2 telah memperbaiki masalah ini. Konten commit-nya adalah sebagai berikut. Jika versi kernel terbaru yang Anda tingkatkan berisi konten ini, maka kompatibel dengan keluarga instans 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).

• Jika Anda menggunakan perintah yum update untuk meningkatkan sistem CentOS 8 ke versi kernel kernel-4.18.0-240 atau lebih baru dalam instans dari keluarga instans tujuan umum frekuensi tinggi hfg6, kernel panic dapat terjadi. Jika masalah ini terjadi, kembalikan ke versi kernel sebelumnya.

Deskripsi masalah: Permintaan pip kadang-kadang timeout atau gagal.

Gambar yang terpengaruh: CentOS, Debian, Ubuntu, SUSE, OpenSUSE, dan Alibaba Cloud Linux.

Penyebab: Alibaba Cloud menyediakan tiga alamat sumber pip berikut. Titik akhir default adalah mirrors.aliyun.com. Instans yang mengakses titik akhir ini harus dapat mengakses Internet. Jika instans Anda tidak diberi alamat IP publik, permintaan pip akan timeout.

• (Default) Internet: mirrors.aliyun.com

• Jaringan internal VPC: mirrors.cloud.aliyuncs.com

• Jaringan internal jaringan klasik: mirrors.aliyuncs.com

Solusi: Anda dapat menggunakan salah satu metode berikut untuk mengatasi masalah ini.

• Metode 1

  Berikan alamat IP publik ke instans Anda dengan menyambungkan EIP ke instans tersebut. Untuk informasi lebih lanjut, lihat Sambungkan EIP ke sumber daya cloud.

  Untuk instans subscription, Anda juga dapat menetapkan ulang alamat IP publik dengan meningkatkan atau menurunkan tipe instans. Untuk informasi lebih lanjut, lihat Tingkatkan tipe instans instans subscription.

• Metode 2

  Jika respons pip tertunda, Anda dapat menjalankan skrip fix_pypi.sh di instans ECS, lalu coba lagi operasi pip. Langkah-langkahnya adalah sebagai berikut:

  1. Terhubung ke instans.

     Untuk informasi lebih lanjut, lihat Terhubung ke instans menggunakan VNC.

  2. Jalankan perintah berikut untuk mendapatkan file skrip.

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

  3. Jalankan skrip tersebut.

     • Instans VPC: Jalankan perintah bash fix_pypi.sh "mirrors.cloud.aliyuncs.com".

     • Instans jaringan klasik: Jalankan perintah bash fix_pypi.sh "mirrors.aliyuncs.com".

  4. Coba lagi operasi pip.

  Konten skrip fix_pypi.sh adalah sebagai berikut:

  #!/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