Answers: <p>Found out that the remote_file resource couldn't handle redirects. Hence I had to write a ruby_block resource that makes use of 'Down' gem.</p>
  
  <pre><code>ruby_block 'download_openvpn_zip' do
      block do 
          attempt = 2
          begin
              retries ||= 0
              tempfile = Down::NetHttp.download("http://www.someurl.com/#{zip},max_redirects: 0)
              FileUtils.mv tempfile.path, "#{node['openvpn-conf-path']}/#{tempfile.original_filename}"
          rescue Down::TooManyRedirects =&gt; e
              puts "\n \t ERROR: #{e.message}"
              retry if (retries += 1) &lt; 1
          end 
      end
      action :run
      notifies :run, 'execute[unzip_file]', :delayed
  end
  </code></pre>
  
Answers: CC BY-SA 4.0
Answers: 2019-01-18T21:52:23.017Z
Answers: Maybe you could have achieved the same thing using the http class of chef, but I'm not really sure. Thanks for sharing your solution anyway :)
Answers: Tensibai
Answers: CC BY-SA 4.0
Answers: 2019-01-18T21:53:56.753Z
Answers: You way have a better experience using `Chef::Log.warn` instead of puts also.
Answers: Tensibai
Answers: CC BY-SA 4.0
Answers: 2019-01-18T22:42:45.873Z
Answers: Thanks for the tip, will be using the Chef::Log.warn instead of puts.
Answers: Yuge
Answers: CC BY-SA 4.0
Answers: 2019-01-18T18:09:05.987Z
Answers: 2019-01-18T18:09:05.987Z
Answers: Yuge
Body: <p>I am trying to implement the below <code>wget</code> download command using chef <code>remote_file</code> resource. But I couldn't find a way to avoid the re-directions. The URL that I am trying to access may sometimes be redirected to my ISP bill reminder page. And chef <code>remote_file</code> resource downloads this bill reminder HTML page as a zip file.</p>
  
  <p><code>wget -N  --max-redirect=0 http://www.someurl.com/file.zip</code></p>
  
  <p>The chef recipe resource is </p>
  
  <pre><code>remote_file "#{node['download-zip-path']}/#{zip}" do
      source "http://www.someurl.com/#{zip}"
      action :create
      notifies :run, 'execute[unzip_file]', :delayed
  end
  </code></pre>
  
  <p>The <code>--max-redirect=0</code> flag in <code>wget</code> makes sure that there isn't any redirection to ISP page. I can achieve the same using ruby's <code>open-uri</code> or <code>execute</code> command resource but is there any native chef way to achieve this no/zero re-direction?</p>
  
Comments: CC BY-SA 4.0
Comments: 2019-01-13T15:55:35.440Z
Comments: No there's not, failing to download would mean failure of run. The proper course of action is to host the target file on an internal server, don't trust remotes to be available
Comments: Tensibai
Comments: CC BY-SA 4.0
Comments: 2019-01-14T14:39:54.587Z
Comments: Thanks for the reply. The chef-client machines are deployed at customer premises and are connected to the internet through the client's ISPs. The file that is downloaded is vpn config and hence hosing on a internal server is not possible. So I will go ahead with a ruby module and add it as a library for my recipes.
Comments: Yuge
Comments: CC BY-SA 4.0
Comments: 2019-01-14T15:02:46.103Z
Comments: Yes, you have to bake that yourself
Comments: Tensibai
Comments: CC BY-SA 4.0
Comments: 2019-01-18T17:58:29.080Z
Comments: @Tensibai I have make use of the Down gem in ruby and write a ruby_block resource.
Comments: Yuge
Tags: <chef>
Title: Chef remote_file set maximum number of re-directions to zero
UserDisplayName: Yuge
ThreadText: # Chef remote_file set maximum number of re-directions to zero
  
  (Asked by: username_0 on 2019-01-11)
  
  I am trying to implement the below `wget` download command using chef `remote_file` resource. But I couldn't find a way to avoid the re-directions. The URL that I am trying to access may sometimes be redirected to my ISP bill reminder page. And chef `remote_file` resource downloads this bill reminder HTML page as a zip file.
  
  `wget -N --max-redirect=0 http://www.someurl.com/file.zip`
  
  The chef recipe resource is
  
  ```
  remote_file "#{node['download-zip-path']}/#{zip}" do
      source "http://www.someurl.com/#{zip}"
      action :create
      notifies :run, 'execute[unzip_file]', :delayed
  end
  
  ```
  
  The `--max-redirect=0` flag in `wget` makes sure that there isn't any redirection to ISP page. I can achieve the same using ruby's `open-uri` or `execute` command resource but is there any native chef way to achieve this no/zero re-direction?
  
  **Tags:** chef
  
  > **Comments:**
  > **username_1**: No there's not, failing to download would mean failure of run. The proper course of action is to host the target file on an internal server, don't trust remotes to be available  
  > **username_0**: Thanks for the reply. The chef-client machines are deployed at customer premises and are connected to the internet through the client's ISPs. The file that is downloaded is vpn config and hence hosing on a internal server is not possible. So I will go ahead with a ruby module and add it as a library for my recipes.  
  > **username_1**: Yes, you have to bake that yourself  
  > **username_0**: @username_1 I have make use of the Down gem in ruby and write a ruby_block resource.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_0 on 2019-01-18. Score: 1 | Accepted answer
  
  Found out that the remote\_file resource couldn't handle redirects. Hence I had to write a ruby\_block resource that makes use of 'Down' gem.
  
  ```
  ruby_block 'download_openvpn_zip' do
      block do 
          attempt = 2
          begin
              retries ||= 0
              tempfile = Down::NetHttp.download("http://www.someurl.com/#{zip},max_redirects: 0)
              FileUtils.mv tempfile.path, "#{node['openvpn-conf-path']}/#{tempfile.original_filename}"
          rescue Down::TooManyRedirects => e
              puts "\n \t ERROR: #{e.message}"
              retry if (retries += 1) < 1
          end 
      end
      action :run
      notifies :run, 'execute[unzip_file]', :delayed
  end
  
  ```
  
  > **Comments:**
  > **username_1**: Maybe you could have achieved the same thing using the http class of chef, but I'm not really sure. Thanks for sharing your solution anyway :)  
  > **username_1**: You way have a better experience using `Chef::Log.warn` instead of puts also.  
  > **username_0**: Thanks for the tip, will be using the Chef::Log.warn instead of puts.  
  
  ---
  
  