3 Replies Latest reply on Mar 4, 2014 7:34 AM by Ray Ward Branched to a new discussion.

    BladeLogic Advanced Repeaters - Version 8.0

    Ray Ward

      We are currently running version 8.0 SP10

      The application server and file server are shared with the database on a separate Unix Oracle instance.

      All of the Bladelogic infrastructure is hosted in the same datacentre


      However, some of the managed servers are located in a remote datacentre and we have a QoS link in place to manage the connectivity.


      This causes us major problems when attempting to complete patch remediation due to the file sizes involved.


      The obvious answer is to have a more localised point of presence.

      This to me would be an advanced repeater to store and forward the patch catalog?


      The problem we have is the fact that I believe the "advanced" function is not supported on version 8.0?


      Is there a way of implementing a later version of the repeater or facilitating a local fileserver to store the patch catalogs?


      I know the real answer is to upgrade the Application as I have not done this an attempt at a workaround maybe a better short term fix




        • 1. Re: BladeLogic Advanced Repeaters - Version 8.0
          Bill Robinson

          patches will not use the ARS, even in 8.3 - the ARS/AFS only handle payloads that are stored under bsa file server management.  patch payloads are considered 'remote' as they are stored on a helper system.


          there are a few things you can do here:


          1 - use the normal nsh repeater but you lose bandwidth controls

          2 - mirror the patch repo to your remote site(s) w/ a file deploy job, dsync, rsync, nas device replication, etc and then use the 'AGENT_MOUNT" url type in the catalog that is parameterized w/ server properties for each location, so that your target servers would mount the remote (local to them) repo via smb or nfs and pull the patches from there.

          1 of 1 people found this helpful
          • 2. Re: BladeLogic Advanced Repeaters - Version 8.0
            Ray Ward


            Thank you for the prompt response.

            As you can see we were all under the impression that the ARS was responsible for this activity, so that's good to get clarified. Its so easy to get an incorrect understanding and for it to spread like wild fire.


            So onto potential solutions.


            1. We have a repeater installed already. This is present under the infrastructure Management GUI under "Repeater Servers". Bandwidth controls don't seem to be of great concern at the moment in fact that we want the patches to be stored locally in the remote server. Is this still a solution we can explain?


            2. Our catalog is already an offline version due to internet restriction so copying the patch repository is indeed a possibility and ultimately has to be done whatever the solution. To obtain them we are using the offline downloader. So to explore this further  where do I go from here:



            • 3. Re: BladeLogic Advanced Repeaters - Version 8.0
              Ray Ward

              Sorry, I branched the discussion elsewhere hoping I could select the paragraph. Instead it has eaten Bill's entire response.

              Included below


              if you want to use the nsh repeater then the repository location and network url for payload deployment settings will be identical and will be like //helperserver/somedir/catalogname and the url type will be 'nsh copy at staging'.  then as long as the repeater rules are setup and the 'stage indirect' is checked on the deploy job(s) you'll use the repeater.


              if you want to do the mirror thing, then assuming you have the mirroring working you would have the repository location be the //helperserver/somdir/catalogname and then the network url would be like smb://??TARGET.SMBUSER??:??TARGET.SMBPASS??/??TARGET.SMBSERVER??/share


              (or whatever the correct format of the smb url type is) - and the ??TARGET.BLAH?? are all server properties that are set on each server at your various locations and resolve to the correct settings so the target can mount the local mirror.