![\"Welcome](\"https://vic.demuzere.be/assets/articles/images/ysz51v8FGjZ3NRJ4U5NQEl4o39AuqWRd.jpg\")
One of the tools I'm maintaining at work is Bunka, a Go CLI application to execute commands in parallel on a list of servers.\nWe're setting the DEBIAN_FRONTEND environment variable to noninteractive for all our connections as we regularly use apt and related commands.\n(If we don't, command execution may hang as a dialog is shown and the process is waiting for user input.)
This week someone created a bug report because their apt-get commands were hanging on multiple servers.\nPretty strange, as this was the exact reason we're setting environment variables in the first place. Let's investigate!
To change environment variable for the currently running process you can use the Setenv function provided by the standard library's os package.\nThis can be useful when you use the os/exec package to start subprocesses.
func Setenv(key, value string) error \nThe ssh package provides a similar function that sets an environment variable on an SSH session.\nThese variables will be available for any command you execute on that same session after changing calling the Setenv function.
func (s *Session) Setenv(name, value string) error\nAs this "simply sets a variable" I was ignoring the errors returned by the Setenv function. After all, what could go wrong when setting a simple environment variable? I couldn't be more wrong.
When I actually checked the error object returned by Setenv it turned out not to be nil. It contained the amazingly useful message below.
ssh: setenv failed\nDiving in the source code for the ssh package we can see that the request to set an environment variable is sent directly to the SSH server, there's not much in that Go code that can go wrong. Also note that it returns the same error message regardless of what went wrong when calling SendRequest.
func (s *Session) Setenv(name, value string) error {\n\tmsg := setenvRequest{\n\t\tName: name,\n\t\tValue: value,\n\t}\n\tok, err := s.ch.SendRequest("env", true, Marshal(&msg))\n\tif err == nil && !ok {\n\t\terr = errors.New("ssh: setenv failed")\n\t}\n\treturn err\n}\nSo let's take a step back and do it without Go:
\n[vic@local ~]$ export DEBIAN_FRONTEND=noninteractive\n[vic@local ~]$ ssh -o SendEnv=DEBIAN_FRONTEND vic@remote\n[vic@remote ~]# echo $DEBIAN_FRONTEND\nNothing, it simply doesn't work.
\nTurns out, you can't simply change environment variables in SSH sessions. The OpenSSH server denies those requests unless you've whitelisted the specific variable in your server settings. This is for security reasons: people with access to a restricted list of commands could set an environment variable like LD_PRELOAD to escape their jail. (If your user has access to a shell there are other ways to set environment variables.)
To allow changing an environment variable over SSH, change the AcceptEnv setting in your OpenSSH server configuration (typically /etc/ssh/sshd_config) to accept your environment variable:
AcceptEnv DEBIAN_FRONTEND\nAnd now it magically works!
\n","url":"https://vic.demuzere.be/articles/environment-variables-setenv-ssh-golang/","date_published":"2020-02-11T19:15:00Z","date_modified":"2025-02-08T09:27:38Z","language":"en"},{"id":"https://vic.demuzere.be/articles/naar-londen-voor-golang-uk-2016/","content_html":"Sinds kort schrijven we bij Openminds enkele interne tools in Go. De tweede editie van GolangUK was dan ook een goede gelegenheid om deze taal beter te leren kennen. De conferentie vond plaats in de prachtige gebouwen van The Brewery in Londen.
\n
Maar eerst: waarom is de populariteit van Go zo sterk toegenomen? Go wordt naar statisch gelinkte binaries gecompileerd. Met andere woorden: ze kunnen overal uitgevoerd worden zonder externe afhankelijkheden. Daarnaast zijn simpele tooltjes ook iets sneller dan de Ruby-varianten die we vroeger gebruikten.
\nVoorafgaand aan GolangUK waren twee workshops voorzien. De keuze bestond uit de Ultimate Go Workshop die een introductie tot de programmeertaal gaf voor mensen die voorlopig enkel ervaring hadden met andere talen. In de Advanced Go Workshop, voor iedereen die wel al iets in Go geknutseld heeft, keken we naar het belang van data-oriented design: goed doordachte datastructuren kunnen een groot verschil maken in performantie. Er werd gehamerd op het belang van simpele en makkelijk te lezen code. Later kwamen ook de verschillende tools aan bod die helpen met het opsporen van code die veel CPU-tijd kost of veel geheugen verbruikt.
\nMet nog niet veel Go-ervaring was het fijn om ondergedompeld te worden in de structuren en details van Go. Dit heeft geholpen om de rest van de conferentie toch wat beter te begrijpen. Komende van een Ruby-achtergrond zijn er toch wel een hoop ideeën die helemaal anders zijn in Go. Een dagje experimenteren met Go was dan ook zeer leerrijk.
\n![\"Joren](\"https://vic.demuzere.be/assets/articles/images/zYDj9vh4vkbAe2LMNAxjCIJfzr4PV7Kg.jpg\")
Voor wie zelf eens door alle voorbeelden en oefeningen wil gaan, is er goed nieuws. Alles staat online en met behulp van play.golang.org kan je ook meteen beginnen spelen met code.
\nDeze was helemaal niet zo praktisch als ik had verwacht. Het bleek een presentatie met input van het publiek te zijn, dus wat dat betreft was ik een beetje teleurgesteld. Het enthousiasme van de presentator maakte dat wel goed. William Kennedy is waarschijnlijk de meest enthousiaste verteller die ik ooit heb gezien. Zijn verhaal was vrij abstract, maar de ludieke voorbeelden en grapjes tussendoor zorgen er wel voor dat zijn boodschap bleef hangen. Zelf onthoud ik vooral het belang van goed gestructureerde code. Iets wat in onze interne go-projectjes momenteel wat achterblijft. Werk aan de winkel dus!
\nNa de workshops was er afgesproken om iets te gaan drinken in een lokale pub, daar kwam echter niet veel volk opdagen. De workshops waren ook iets optioneels vooraf aan de conferentie waardoor er sowieso minder mensen waren.
\nDonderdagochtend lag de focus (zoals in de workshop) opnieuw op het schrijven van idiomatische code. Een verzamelnaam voor verschillende afspraken en richtlijnen die de Go-community heeft om code duidelijk, leesbaarder en efficient te maken.
\n![\"Golang](\"https://vic.demuzere.be/assets/articles/images/VKl6elroLDVaMissWUc8SHcofGvHOEUr.jpg\")
De trend van microservices en containers is ook duidelijk zichtbaar, misschien zelfs een beetje te veel. De onderwerpen tracability (het opsporen van requests doorheen verschillende services), logging en statistieken via Prometheus komen vaak terug. Ook talks die over iets anders lijken te gaan raken vaak aan het onderwerp. De focus had wat meer over de Go-taal zelf mogen liggen.
\nDonderdagavond was eindelijk het moment aangebroken waarvoor iedereen stiekem kwam: het sociale event. Buiten was een we-doen-alsof-we-in-een-tropisch-land-zitten terrasje ingericht en de organisatie zorgde voor een lekkere barbecue.
\nDe catering op GolangUK was overigens tijdens heel de conferentie dik in orde! We konden zelf onze gerechten samenstellen door 3 soorten koude slaatjes (vlees, vis of enkel groenten) te combineren met 3 keuzes in warme gerechtjes: ook weer vlees, vis of vegetarisch.
\nDe eerste interessante talk was "How to raise a Gopher", waarin Tiffany Jernigan uitlegt hoe ze in korte tijd Go heeft geleerd en haar ervaring met ons deelt. Heel interessant, vooral omdat bij Openminds ook veel mensen voor de eerste keer in contact komen met de programmeertaal. Ze gaf een mooi overzicht van de online (en in mindere mate geprinte) bronnen die haar geleerd hebben hoe ze in Go aan de slag moest.
\nDaarna, bij gebrek aan beter, een inkijk in iOS en Android apps die gebruikmaken van Go Mobile. Het idee is dat de mobiele apps nog steeds in de native talen voor elk van beide platformen geschreven worden, maar dat ze wel gebruik kunnen maken van een Go-library voor de gedeelde logica. De Go Mobile tool zorgt voor de nodige koppelingen.
\nDe beste talk van vrijdag was van Liz Rice, die op een verrassend interessante manier toonde wat een container nu eigenlijk is. Waar de meesten een ingewikkelde rede over namespaces en cgroups voeren, implementeerde Liz een container in Go. Stap per stap, of eerder syscall per syscall, toonde ze hoe een proces meer en meer afgezonderd werd van de rest van het systeem. In een klein half uurtje had ze zo een Go-programma met een eigen filesystem, hostname en afgezonderde procesnummers (PIDs).
\nOok op vrijdag bleken veel talks te raken aan de microservices, dus het was soms een beetje zoeken om niet nog eens dezelfde argumenten te horen.
\nGolangUK had helaas geen closing keynote om op een mooie manier af te sluiten. Na de laatste presentatie was de conferentie plots gedaan. Daar schoot de verder prima verlopen conferentie toch iets te kort.
\nVoor we dag nadien naar huis vertrekken toch nog eens opscheppen (pun intended) aan het ontbijt.
\n","url":"https://vic.demuzere.be/articles/naar-londen-voor-golang-uk-2016/","date_published":"2016-08-30T12:00:00Z","date_modified":"2026-05-13T17:21:53Z","language":"nl"},{"id":"https://vic.demuzere.be/articles/golang-makefile-crosscompile/","content_html":"When a new version of one of my Go apps is ready, I usually want to build and package the binary for multiple platforms.\nThis can easily be done in a shell script, but Make brings a bonus: it can run multiple builds at the same time.
\nIn case you've worked with make before, skip this section!\nIf not: let's see what a basic makefile looks like.
\nMake defines targets, these are things that need to be done.\nUsually a target represents a file that has to be created.\nEvery target contains a list of commands that have to be executed, we call that the recipe.\nMake will only execute the recipe if a file with the same name as the target does not exist.\nIf your target does not represent a file, it's a phony target.
\nmytarget:\n\techo Hello world.\n\nspace: mytarget foo\n\techo "I'm in space."\n\nfoo:\n\techo I am run only once\n\ttouch foo\n\n.PHONY: mytarget space\nThe above makefile contains 3 targets: mytarget, foo and space.\nThe second target tells us that it needs both other targets, so when you call make space, make will also execute mytarget and foo.
At the bottom of the file we define a special .PHONY target: Here we simply tell make which targets are phony targets.\nThose do not represent a file on disk.\nAs we usually don't compile separate Go files, most of our targets will be phony targets.
\nLet's see what this does: save the file as Makefile and run make space in the same directory:
$ make space \necho Hello world.\nHello world.\necho I am run only once\nI am run only once\necho "I'm in space."\nI'm in space.\nNotice that make always tells us what command it is executing.\nYou can hide a command by prefixing it with @.\nAs we'll be executing multiple targets concurrently, it may be useful to see which commands are running.
\nRun make space again.\nYou'll see that the foo target is not run anymore.\nThat's because we created a file named foo and foo is not a phony target.
GNU Make has two types of variables.\nWhen we assign to a variable with := the contents is evaluated at the time the variable is declared.\nIf we use just = the contents is evaluated every time we use the variable.
MYVAR := Hello there! I am currently in $(shell pwd)\nPWD = $(shell pwd)\nThe pwd shell command will be executed every time we use variable $(PWD) in the makefile, while $(MYVAR) will always contain the same value.
Make supports running multiple targets at the same time.\nThis means that we need a separate target for every GOOS and GOARCH in order to take advantage of the concurrency.
\nA simple way to do this would be:
\nlinux:\n\tGOOS=linux GOARCH=amd64 go build ...\n\nwindows:\n\tGOOS=windows GOARCH=amd64 go build ...\n\nrelease: windows linux\n\n.PHONY release windows linux\nThis builds both linux and windows binaries when we call make release.\nWe can improve this Makefile by looping over the platforms and architectures we want to build:
PLATFORMS := linux/amd64 windows/amd64\n\nrelease: $(PLATFORMS)\n\n$(PLATFORMS):\n\techo Hello, I am $@\n\n.PHONY release $(PLATFORMS)\nWhat we do here is create a target that contains all possible platforms.\nEvery platform is a separate target, just like it was in the previous Makefile.\nThat also means that we have to add every platform to the phony list.\nLuckily, we can do that using the same variable. Inside the recipe we can use the special $@ that contains the name of the current target.
The next part is a bit harder, we need to separate OS and ARCH.\nRemember that variables can be evaluated at runtime?\nWe'll use that feature to create an $(os) and $(arch) var.
temp = $(subst /, ,$@)\nos = $(word 1, $(temp))\narch = $(word 2, $(temp))\nString manipulation functions in make are limited, so we have to be a bit creative here.\nWe'll use these variables inside the $(PLATFORM) target.\nRemember that $@ contains the name of the current target?\nWhen we replace the slash in this string we can use the word function to get the first and last part.
Combined with our previous Makefile, this becomes:
\nPLATFORMS := linux/amd64 windows/amd64\n\ntemp = $(subst /, ,$@)\nos = $(word 1, $(temp))\narch = $(word 2, $(temp))\n\nrelease: $(PLATFORMS)\n\n$(PLATFORMS):\n\tGOOS=$(os) GOARCH=$(arch) go build -o '$(os)-$(arch)' mypackage\n\n.PHONY release $(PLATFORMS)\nNote that variables can only be set outside the recipe.\nAs the contents is only evaluated when we use them, it still contains the correct value.
\nWe now have a Makefile that creates binaries for the platforms we listed in the $(PLATFORMS) variable.\nWhen we call make release it builds everything we asked, one by one.\nThe main reason to use make is the easy concurrency: simply call make with the -j n argument, where n is the number of simultaneous jobs.