Đăng ký thành công chỉ xác nhận quyền truy cập dịch vụ thuê bao. Siêu dữ liệu kho DNF và việc tải gói có thể dùng cấu hình và tên máy chủ khác, nên hãy bắt đầu từ ID kho, URL thực tế và lỗi đầu tiên của thao tác thất bại.

Với subscription-manager, phần server trong /etc/rhsm/rhsm.conf dùng các trường riêng:

[server]
proxy_hostname = proxy.example.net
proxy_port = 8080
proxy_user = service-account
proxy_password = REPLACE_WITH_MANAGED_SECRET

Thay các giá trị này trong cấu hình hiện có và bảo vệ tệp chứa bí mật thật. proxy_hostname nhận tên máy chủ, không phải URL đầy đủ có thông tin xác thực.

Với DNF, hãy kiểm tra kho bị ảnh hưởng và cấu hình chính. Tùy chọn proxy là một URL; proxy_username, proxy_password và proxy_auth_method là các tùy chọn riêng. Một kho có thể ghi đè giá trị toàn cục. Thiếu tùy chọn proxy có thể cho phép tra cứu từ môi trường, trong khi giá trị rỗng rõ ràng sẽ tắt giá trị cha đã cấu hình cho phần đó. Hãy theo tài liệu của thế hệ DNF đã cài. Với DNF 4: tách kế thừa của kho khỏi quy tắc bỏ qua môi trường.

Nếu tệp kho do công cụ thuê bao tạo ra, hãy xác định chủ sở hữu đó trước khi sửa. Thay đổi bị ghi đè khi làm mới thuộc về nguồn cấu hình được hỗ trợ, không phải việc sửa lặp lại tệp đầu ra.

Sau đó phân loại lỗi đầu tiên. Kết nối tới proxy xảy ra trước bước kiểm tra tài khoản của cả hai dịch vụ. 407 yêu cầu xác thực proxy; lỗi TLS liên quan đến tin cậy của kết nối đang lỗi; bị nguồn gốc từ chối liên quan đến quyền truy cập thuê bao hoặc kho. Máy chủ CDN của gói có thể khác máy chủ đăng ký, nên danh sách cho phép của bên này không chứng minh quyền truy cập bên kia.

Giữ lại điểm cuối thực tế, proxy đã chọn và định danh tài khoản ở mỗi lần so sánh, không kèm bí mật. Các công thức cũ với rhn_register và /etc/sysconfig/rhn/up2date mô tả một thế hệ công cụ khác và không xác định cấu hình của yêu cầu RHSM hay DNF hiện tại.

Bài viết liên quan