I have a couple of systems at home which provide web services, like my Intel NUC
and my Synology NAS, and I have been wanting for a while to move all of them to
a proper https only environment.
But my biggest hurdle for doing that, has been the enormous pain in managing
certificates in a way that makes everybody - the servers, the browsers, the
local http clients happy. From my previous attempts, there was always the
browsers which annoyed me to no end, and I ended up getting by using improperly
made self-signed certificates and accepting all the invalid certificate warnings
that my browser threw up.
So this Friday night, I spent my late night hours trying to get at the bottom of
it all, and several frustrating hours later, finally made everybody happy.
If you add this bit of code in the <head> section of an HTML 5 page, clicking on
every link will open in a new tab.
<basetarget="_blank">
This tag is mostly used to set a URL to resolve all relative links on a page. But it offers
an additional attribute target to set a default target policy for links.
You can, of course, override the target attribute on a link to link basis, if you are using this feature.
The default Ansible privilege escalation mechanism requires broad sudo
privileges. If your production environment gives you sudo access but bars you
from getting a root shell, you are out of luck. As, the doc says - you cannot
expect Ansible to work when sudo commands are restricted.
Privilege escalation permissions have to be general. Ansible does not always
use a specific command to do something but runs modules (code) from a
temporary file name which changes every time. If you have /sbin/service or
/bin/chmod as the allowed commands this will fail with ansible as those
paths won’t match with the temporary file that ansible creates to run the
module.
I seem to learn more about the nuances of the Go language every other day. Sometime back, I had looked at how Go untyped constants work during maths operations with typed variables.
I just found another significant part of the spec that I had previously glossed over, this one is also about untyped constants - numeric constants in Go live in an unified space with arbitrary precision and a fungible numeric type.
So I ran into this problem at work today with an runit based service breaching open files limit.
My first thought was to increase the system ulimit for nofile in /etc/security/limits.conf. I changed this
from 30k to about 60k. But strangely, the service still keep dying.
Sometimes instead of creating a logger and then passing it around, it is convenient to just use a
global logger.
The standard log library allows you to both create a custom logger using
log.New() or directly use a standard logger instance by calling
the package helper functions log.Printf() and the like.
zap provides such a functionality as well using zap.L() and zap.S(), however using them
didn’t seem so straight forward to me.
The various implementations of field encoders provided in zap can sometimes feel inadequate. For
example, you might want the logging output to be similar to that in syslog or other common log
formats. You might want the timestamps in the log to ignore seconds, or the log level to be wrapped
within square brackets.
To have your own custom formatters for the metadata fields you need to write custom encoders.
Using the logger presets in zap can be a huge time saver, but if you really need to tweak the
logger, you need to explore ways to create custom loggers. zap provides an easy way to create
custom loggers using a configuration struct. You can either create the logger configuration using a
JSON object (possibly kept in a file next to your other app config files), or you can statically
configure it using the native zap.Config struct, which we will explore here.
I was intrigued when Uber announced zap, a logging library for Go with claims of really high
speed and memory efficiency. I had tried structured
logging earlier using logrus, but while I did not experience
it myself, I was worried by a lot of folks telling me about its performance issues at high log
volumes. So when zap claimed performance exceeding the log package from standard library, I had
to try it. Also, its flexible framework left the door open to a future plan of mine of sending logs
filebeat style to ELK.
The documentation for the library was pretty standard, but I
could not find a reasonable introduction to explore the various ways one can use the library. So I
decided to document some of my experiments with the library.
I collected my code examples in Github, and decided to
break it up into a series of posts.
I admit I had not paid much attention to Netlify earlier. It sort of seemed like yet another web performance related startup.
But on reading Fatih’s article on hosting Hugo on Netlify, it piqued my interest. A CDN/hosting service which puts your content in caches all around the world, and triggers Hugo (and bunch of other common scripts) on Github commits? And all this for free? Sounds too good to be true, and memories of Posterous floated in my mind.
But again, the best part of using static blogging software like Hugo, is that there is so less to lose from trying out a new hosting option - no databases to setup, no old content to migrate.
And so i decided to try it out as well. And it turned out to be blindingly simple! Netlify turned out to be awesome!
Here are all the stuff I needed to do to move my Hugo hosting from my shared hosting account at Dreamhost to Netlify.
