BSA: RHEL 7 Patch Catalog update job is failing "URL returned error: 403 Forbidden"

Version 4
    Share:|

    This document contains official content from the BMC Software Knowledge Base. It is automatically updated when the knowledge article is modified.


    PRODUCT:

    BladeLogic Server Automation Suite


    COMPONENT:

    BladeLogic Patch Management


    APPLIES TO:

    RHEL 7 patch catalog update in BSA version 8.6 onwards



    PROBLEM:

    A BMC BladeLogic Server Automation (BSA) RHEL7 Patch catalog update job is failing and the following error is seen in the Job Run logs :
     
    Validation Error :- BLPAT1211 - Unable to find sqlite db required by yum.
    Possible remediation steps :- Please check the yum_metadata_generator.log file generated in repo directory
     
    The yum_metadata_generator.log which is created on the repository server under the “Repository Location” specified in the Patch Catalog Update job has something like the following :
     
    Started executing yum metadata generator script
    Thu May 19 16:03:20 IST 2016 : cache dir path is /data/BMC_Test/cachedir
    Config time: 0.037
    Yum Version: 3.2.29
    https://cdn.redhat.com/content/dist/rhel/server/7/7Server/x86_64/os/repodata/repomd.xml: [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 403 Forbidden"
    Trying other mirror.
    https://cdn.redhat.com/content/dist/rhel/server/7/7Server/x86_64/os/repodata/repomd.xml: [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 403 Forbidden"
    Trying other mirror.
    repo id            repo name                                              status
    rhel-7-server-rpms Red Hat Enterprise Linux Server (v. 7 for 64-bit x86_6 0
    repolist: 0
    Thu May 19 16:03:59 IST 2016 : No Repo DB Found, Command Exit Code - 0
     


    CAUSE:

    The certificates downloaded as a part of pre-requisite for RHEL7 Patch Catalog Creation have been revoked by Red Hat.


    SOLUTION:

    Redhat occasionally revokes certificates to ensure its accuracy.
     
    Please see below link.

    https://access.redhat.com/solutions/1290153
     

    “A subscription entitlement certificate can be revoked any time by Red Hat to ensure its accuracy. Constantly Red Hat is updating the SKUs descriptions, accounts modifications, subscriptions renewals/models, etc. Since this certificate is used to grant access to the products on CDN, to guarantee that this certificate reflects the current changes/updates, it will automatically be marked as dirty, which in other words means that the certificate needs to be regenerated and re-downloaded on the client. Note that Red Hat can mark this certificate as dirty any time, even when no changes are made on your account.”
     
    The only option in this case is to regenerate and download the certificates and re-run a catalog update job.


    The procedure to download the certificates is mention in the document below.

    RH6:
    https://docs.bmc.com/docs/ServerAutomation/89/creating-a-patch-catalog-for-rhel-6-676353746.html

    RH7:
    https://docs.bmc.com/docs/ServerAutomation/89/creating-a-patch-catalog-for-rhel-7-676334473.html

    The section below contains all the exact steps to download the certificates.
     

      

    Also see the following video created by BMC Customer Support on this topic: 

    https://www.youtube.com/watch?v=Yzk3P5Sy2Nk
       

    One option is to run a NSH Script Job periodically to update the settings in Patch Global Config.  There should only be one set of certificates in the /etc/pki/entitlements directory so we can run something like the below:

      

    #!/bin/nsh

      

     

      
    #blcli_setoption serviceProfileName defaultProfile
      
    #blcli_setoption roleName BLAdmins
      
    # uncomment above for interactive run
      
    blcli_connect
      
    repoHost="blprov01-88.local"
      
    certDirectory="/etc/pki/entitlement"
      
    cfgFile="/tmp/pgc.$$"
      
    blcli_execute FileServer getHost
      
    blcli_storeenv fsHost
      
    blcli_execute FileServer getRootPath
      
    blcli_storeenv fsRoot
      
    fileServer="//${fsHost}${fsRoot}"
      
    certFile="$(find "//${repoHost}${certDirectory}" -name "*.pem" ! -name "*key.pem" -print)"
      
    keyFile="$(find "//${repoHost}${certDirectory}" -name "*key.pem" -print)"
      
    echo "Found Cert: ${certFile}"
      
    echo "Found Key: ${keyFile}"
      
    echo "REDHAT.RH_SSL_CLI_CERT_FILE_OPTION=${certFile}" >> "${cfgFile}"
      
    echo "REDHAT.RH_SSL_CLI_KEY_FILE_OPTION=${keyFile}" >> "${cfgFile}"
      
    blcli_execute PatchGlobalConfiguration setPatchGlobalConfigurationOptions "${cfgFile}"
      
    # move the old ones out of the way since the above only updates the database
      
    [[ -f "${fileServer}/patch/GlobalConstants/rh-sslclientcert.pem" ]] && rm -f "${fileServer}/patch/GlobalConstants/rh-sslclientcert.pem"
      
    [[ -f "${fileServer}/patch/GlobalConstants/rh-sslclientkey.pem" ]] && rm -f "${fileServer}/patch/GlobalConstants/rh-sslclientkey.pem"
      
    cp "${certFIle}" "${fileServer}/patch/GlobalConstants/rh-sslclientcert.pem"
      
    cp "${keyFile}" "${fileServer}/patch/GlobalConstants/rh-sslclientkey.pem"
      
    [[ -f "${cfgFile}" ]] && rm -f "${cfgFile}"
      

    This is a blind update - there is no blcli call to see what the current setting is to compare. This could be scheduled to run before the RedHat CUJ to ensure any certificate changes are reflected in the PGC settings.

      

    Please raise a support ticket if the problem is not resolved after following these steps. 

      

     


    Article Number:

    000114000


    Article Type:

    Solutions to a Product Problem



      Looking for additional information?    Search BMC Support  or  Browse Knowledge Articles