Answers: <p>If I understand the question correctly, the problem isn't really related to ansible at all. What you need is a package repository on the local network that can cache or mirror public packages.</p>
  <p>There are a number of deb specific options like <a href="https://help.ubuntu.com/community/Rsyncmirror" rel="nofollow noreferrer">rsyncmirror</a> or <a href="https://apt-mirror.github.io/" rel="nofollow noreferrer">apt-mirror</a>. There are also generic options that hold many different types of binaries and package feeds, like <a href="https://jfrog.com/artifactory/" rel="nofollow noreferrer">artifactory</a> or <a href="https://www.sonatype.com/products/repository-pro" rel="nofollow noreferrer">sonatype nexus</a>. On top of being able to get your packages into your private network they offer varying levels of control over what packages are made available within the environment. Once you have a local repository on the network, you could use ansible to update the apt sources.list to pull from the local url instead of the internet based repos.</p>
  <p>If you don't need any control over what packages are available, making internet repos available through a proxy is also an option, but the above solutions scale better long term.</p>
  
Answers: CC BY-SA 4.0
Answers: 2021-07-20T18:34:29.510Z
Answers: Thanks for your input.
Answers: tango91a
Answers: CC BY-SA 4.0
Answers: 2021-07-20T17:06:37.657Z
Answers: 2021-07-20T17:12:07.750Z
Answers: 2021-07-20T17:12:07.750Z
Answers: Mike Frank
Body: <p>I am quite new to Ansible, and have to been able to use it to install packages on 80 remote Ubuntu servers that have no external internet access.</p>
  <p>Is it possible to use Ansible to update/patch these Ubuntu servers that have no external internet access? Something similar to running &quot;sudo apt upgrade&quot; on these servers if they had internet access. Is using Ansible a viable solution/option?</p>
  <p>I have researched online but no joy. Any assistance or guidance on how to use Ansible to patch/upgrade remote Ubuntu servers that have no external internet access?</p>
  
Tags: <ansible><ubuntu>
Title: Using ansible to update remote Ubuntu servers that have no external internet access
UserDisplayName: tango91a
ThreadText: # Using ansible to update remote Ubuntu servers that have no external internet access
  
  (Asked by: username_0 on 2021-07-19)
  
  I am quite new to Ansible, and have to been able to use it to install packages on 80 remote Ubuntu servers that have no external internet access.
  
  Is it possible to use Ansible to update/patch these Ubuntu servers that have no external internet access? Something similar to running "sudo apt upgrade" on these servers if they had internet access. Is using Ansible a viable solution/option?
  
  I have researched online but no joy. Any assistance or guidance on how to use Ansible to patch/upgrade remote Ubuntu servers that have no external internet access?
  
  **Tags:** ansible, ubuntu
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2021-07-20. Score: 1 | Accepted answer
  
  If I understand the question correctly, the problem isn't really related to ansible at all. What you need is a package repository on the local network that can cache or mirror public packages.
  
  There are a number of deb specific options like [rsyncmirror](https://help.ubuntu.com/community/Rsyncmirror) or [apt-mirror](https://apt-mirror.github.io/). There are also generic options that hold many different types of binaries and package feeds, like [artifactory](https://jfrog.com/artifactory/) or [sonatype nexus](https://www.sonatype.com/products/repository-pro). On top of being able to get your packages into your private network they offer varying levels of control over what packages are made available within the environment. Once you have a local repository on the network, you could use ansible to update the apt sources.list to pull from the local url instead of the internet based repos.
  
  If you don't need any control over what packages are available, making internet repos available through a proxy is also an option, but the above solutions scale better long term.
  
  > **Comments:**
  > **username_0**: Thanks for your input.  
  
  ---
  
  