<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Network on Giedrius Statkevičius</title><link>https://giedrius.blog/categories/network/</link><description>Recent content in Network on Giedrius Statkevičius</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Thu, 22 Nov 2018 17:36:50 +0000</lastBuildDate><atom:link href="https://giedrius.blog/categories/network/feed.xml" rel="self" type="application/rss+xml"/><item><title>/etc/nsswitch.conf and /etc/hosts woes with the Alpine (and others) Docker image and Golang</title><link>https://giedrius.blog/2018/11/22/etc-nsswitch-conf-and-etc-hosts-woes-with-the-alpine-and-others-docker-image-and-golang/</link><pubDate>Thu, 22 Nov 2018 17:36:50 +0000</pubDate><guid isPermaLink="false">https://giedrius.blog/?p=257</guid><description>&lt;p&gt;By default, the &lt;code&gt;alpine&lt;/code&gt; Docker image which is mostly used for Golang programs does &lt;a href="https://github.com/gliderlabs/docker-alpine/issues/367"&gt;&lt;em&gt;not&lt;/em&gt;&lt;/a&gt; contain &lt;code&gt;/etc/nsswitch.conf&lt;/code&gt;. Golang&amp;rsquo;s &lt;code&gt;net&lt;/code&gt; package used to do a sane thing when that file did not exist back in the day (before April 30, 2015) i.e. they checked the &lt;code&gt;/etc/hosts&lt;/code&gt; file first, and then moved on to trying to query the DNS servers.&lt;/p&gt;
&lt;p&gt;However, it was changed later - now Go&amp;rsquo;s resolver tries to query the local machine as per the manual page of &lt;a href="http://man7.org/linux/man-pages/man5/nsswitch.conf.5.html"&gt;&lt;em&gt;nsswitch.conf(5)&lt;/em&gt;&lt;/a&gt;. You can find the commit &lt;a href="https://go-review.googlesource.com/c/go/+/9380/"&gt;here&lt;/a&gt;.&lt;/p&gt;</description></item><item><title>Do not forget to open 443 port while using ovftool on ESXi hosts and deploying to a vCenter</title><link>https://giedrius.blog/2017/10/12/do-not-forget-to-open-443-port-while-using-ovftool-on-esxi-hosts/</link><pubDate>Thu, 12 Oct 2017 17:07:00 +0000</pubDate><guid isPermaLink="false">http://giedrius.blog/?p=49</guid><description>&lt;p&gt;There is a pretty neat tool called ovftool that makes it easy to deploy an OVA/OVF from any source or extract the contents of an OVA. Ordinarily people would run it on their own machines but it is possible to run it on an ESXi host as well as per these articles: &lt;a href="http://www.virtuallyghetto.com/2012/05/how-to-deploy-ovfova-in-esxi-shell.html"&gt;http://www.virtuallyghetto.com/2012/05/how-to-deploy-ovfova-in-esxi-shell.html&lt;/a&gt;, &lt;a href="https://gist.github.com/ruzickap/fda71997083a41b0c6cd"&gt;https://gist.github.com/ruzickap/fda71997083a41b0c6cd&lt;/a&gt;. However, if you tried that and tried to deploy the OVA on another vCenter from an ESXi machine you would have ran into a similar error as per this fictional example:&lt;/p&gt;</description></item><item><title>Short tale about proxies and /etc/hosts on GNU/Linux</title><link>https://giedrius.blog/2017/09/02/proxies-and-etc-hosts-on-gnu-linux/</link><pubDate>Sat, 02 Sep 2017 19:14:25 +0000</pubDate><guid isPermaLink="false">http://giedrius.blog/?p=36</guid><description>&lt;p&gt;&lt;img loading="lazy" src="https://giedrius.blog/wp-content/uploads/2017/09/linux-box.png"&gt;&lt;/p&gt;
&lt;p&gt;I encountered an interesting behavior the other day when trying to use HTTP and/or HTTPS proxy on a GNU/Linux machine. cURL and friends read environment variables called &lt;em&gt;http_proxy&lt;/em&gt; and &lt;em&gt;https_proxy&lt;/em&gt;. So, you are thinking, if one wants to have “global” proxy settings, one just has to create a new executable file that is only writable by root in &lt;em&gt;/etc/profile.d&lt;/em&gt; with content like this:&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"&gt;&lt;code class="language-bash" data-lang="bash"&gt;&lt;span style="display:flex;"&gt;&lt;span&gt;&lt;span style="color:#75715e"&gt;#!/bin/sh
&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt;export http_proxy&lt;span style="color:#f92672"&gt;=&lt;/span&gt;”http://1.2.3.4”
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt;export https_proxy&lt;span style="color:#f92672"&gt;=&lt;/span&gt;”$http_proxy”
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;However, you might just notice an confusing occurrence when trying to use hostnames like localhost to refer to your own machine. Unfortunately, the priority is given to the proxy setting regardless if the hostname is static (i.e. it is in &lt;em&gt;/etc/hosts&lt;/em&gt;) and it resolves to a local IP like 127.0.0.1. It could happen that your proxy will be a bit stupid and resolve localhost to its own (or even a different) IP, and then you will get burned because you want to refer to your computer with it, not the proxy IP. It has potential to especially be confusing if the output will be very similar to what you are expecting. This can happen when e.g. you are trying to set up a simple web server on your machine and the proxy responds with a place holder page. I can confess that I fell into this trap but I will not anymore.&lt;/p&gt;</description></item></channel></rss>