#+hugo_base_dir: ../

* Comunidades difíceis                              :portugues:thoughts:rant:
:PROPERTIES:
:EXPORT_FILE_NAME: comunidades-dificeis
:END:
Uma constante em minha vida há muitos anos é o envolvimento com
comunidades de Software Livre.  É uma parte integral daquilo que me
faz me sentir completo e feliz, e por isso eu não gosto de pensar que
a possibilidade de poder dedicar meu tempo livre (e ocupado também!)
pra tornar esse envolvimento concreto seja algo trivial.  Pelo
contrário: até hoje, mais de 15 anos depois da minha primeira
contribuição pra um projeto Livre, eu ainda me pego agradecendo pelo
privilégio de poder fazer daquilo que eu acredito algo que permeia
minha vida.  Mas é claro que nem tudo são flores.

"Comunidade" é só um nome bonito que a gente usa pra "um monte de
pessoas juntas".  E pessoas são complicadas, obviamente.  Ainda mais
aquelas que lidam com um ramo tão complexo, volátil e competitivo como
o da computação.  Por algum motivo, algumas comunidades agem como ímãs
de pessoas mais complicadas, e ultimamente eu tenho pensado bastante
nisso.  Pra mim, é sempre um mistério entender o porquê de alguém
perder seu tempo pra dificultar o trabalho de outros.

* DONE Using WireGuard to host services at home :english:howto:selfhost:wireguard:debian:
CLOSED: [2023-05-23 Tue 00:56]
:PROPERTIES:
:EXPORT_FILE_NAME: using-wireguard-host-services-home
:END:

It's been a while since I had this idea to leverage the power of
[[https://wireguard.org][WireGuard]] to self-host stuff at home.  Even though I pay for a proper
server somewhere in the world, there are some services that I don't
consider critical to put there, or that I consider *too* critical to
host outside my home.

** It's only NATural

With today's ISP packages for end users, I find it very annoying the
amount of trouble they create when you try to host anything at home.
Dynamic IPs, NAT/CGNAT, port-blocking, traffic shapping are only a few
examples of methods or limitations that prevent users from making
local services reachable in a reliable way from outside.

** WireGuard comes to help

If you already pay for a VPS or a dedicated server somewhere, why not
use its existing infrastructure (and public availability) in your
favour?  That's what I thought when I started this journey.

My initial idea was to use a reverse proxy to redirect external
requests to the service running at my home.  But how could I make sure
that these requests reach my
dynamic-IP-behind-a-NAT-behind-another-NAT?  Well, let's create a
tunnel!  WireGuard is the perfect tool for that because of many
things: it's stateless, very performant, secure, and requires very
little configuration.

** Setting up on the server

On the server side (i.e., VPS or dedicated server), you will create
the first endpoint.  Something like the following should do:

#+begin_src
[Interface]
PrivateKey = PRIVATE_KEY_HERE
Address = 10.0.0.1/32
ListenPort = 51821

[Peer]
PublicKey = PUBLIC_KEY_HERE
AllowedIps = 10.0.0.2/32
PersistentKeepalive = 10
#+end_src

A few interesting points to note:

- The =Peer= section contains information about the home service that
  will be configured below.
- I'm using =PersistentKeepalive= because I have a dynamic IP at my
  home.  If you have a static IP, you could get rid of
  =PersistentKeepalive= and specify an =Endpoint= here (don't forget
  to set a =ListenPort= *below*, in the =Interface= section).
- Now you have an IP where you can forward requests to.  If we're
  talking about HTTP traffic, Apache and nginx are absolutely capable
  of doing it.  If we're talking about other kind of traffic, you
  might want to look into other utilities, like [[https://www.haproxy.org/][HAProxy]], [[https://traefik.io/traefik/][Traefik]] and
  others.

** Setting up at your home

At your home, you will configure the peer:

#+begin_src
[Interface]
PrivateKey = PRIVATE_KEY_HERE
Address = 10.0.0.2/32

[Peer]
PublicKey = PUBLIC_KEY_HERE
AllowedIps = 10.0.0.1/32
Endpoint = YOUR_SERVER:51821
PersistentKeepalive = 10
#+end_src

** A few notes about security

I would be remiss if I didn't say anything about security, especially
because we're talking about hosting services at home.  So, here are a
few recommendations:

- Make sure to put your services in a separate local network.  Using
  VLANs is also a good option.
- Don't run services on your personal (or work!) computer, even if
  they'll be running inside a VM.
- Run a firewall on the WireGuard interface and make sure that you
  only allow traffic over the required ports.

Have fun!

* DONE Ubuntu debuginfod and source code indexing :english:ubuntu:debuginfod:debian:free_software:gdb:
CLOSED: [2023-05-13 Sat 16:43]
:PROPERTIES:
:EXPORT_FILE_NAME: ubuntu-debuginfod-source-code-indexing
:END:
You might remember that in my [[/posts/debuginfod-is-coming-to-ubuntu/][last post]] about the [[https://debuginfod.ubuntu.com][Ubuntu debuginfod
service]] I talked about wanting to extend it and make it index and
serve source code from packages.  I'm excited to announce that this is
now a reality since the Ubuntu Lunar (23.04) release.

The feature should work for a lot of packages from the archive, but
not all of them.  Keep reading to better understand why.

** The problem

While debugging a package in Ubuntu, one of the first steps you need
to take is to install its source code.  There are some problems with
this:

- =apt-get source= required =dpkg-dev= to be installed, which ends up
  pulling in a lot of other dependencies.
- GDB needs to be taught how to find the source code for the package
  being debugged.  This can usually be done by using the =dir=
  command, but finding the proper path to be is usually not trivial,
  and you find yourself having to use more "complex" commands like
  =set substitute-path=, for example.
- You have to make sure that the version of the source package is the
  same as the version of the binary package(s) you want to debug.
- If you want to debug the libraries that the package links against,
  you will face the same problems described above for each library.

So yeah, not a trivial/pleasant task after all.

** The solution...

Debuginfod can index source code as well as debug symbols.  It is
smart enough to keep a relationship between the source package and the
corresponding binary's Build-ID, which is what GDB will use when
making a request for a specific source file.  This means that, just
like what happens for debug symbol files, the user does not need to
keep track of the source package version.

While indexing source code, debuginfod will also maintain a record of
the relative pathname of each source file.  No more fiddling with
paths inside the debugger to get things working properly.

Last, but not least, if there's a need for a library source file and
if it's indexed by debuginfod, then it will get downloaded
automatically as well.

** ... but not a perfect one

In order to make debuginfod happy when indexing source files, I had to
patch =dpkg= and make it always use =-fdebug-prefix-map= when
compiling stuff.  This GCC option is used to remap pathnames inside
the DWARF, which is needed because in Debian/Ubuntu we build our
packages inside chroots and the build directories end up containing a
bunch of random cruft (like =/build/ayusd-ASDSEA/something/here=).  So
we need to make sure the path prefix (the =/build/ayusd-ASDSEA= part)
is uniform across all packages, and that's where =-fdebug-prefix-map=
helps.

This means that the package *must* honour =dpkg-buildflags= during its
build process, otherwise the magic flag won't be passed and your DWARF
will end up with bogus paths.  This should not be a big problem,
because most of our packages do honour =dpkg-buildflags=, and those
who don't should be fixed anyway.

** ... especially if you're using LTO

Ubuntu enables [[https://gcc.gnu.org/onlinedocs/gccint/LTO-Overview.html][LTO]] by default, and unfortunately we are affected by an
[[https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109805][annoying (and complex) bug]] that results in those bogus pathnames not
being properly remapped.  The bug doesn't affect all packages, but if
you see GDB having trouble finding a source file whose full path
starts without =/usr/src/...=, that is a good indication that you're
being affected by this bug.  Hopefully we should see some progress in
the following weeks.

** Your feedback is important to us

If you have any comments, or if you found something strange that looks
like a bug in the service, please reach out.  You can either send an
email to my [[https://lists.sr.ht/~sergiodj/public-inbox][public inbox]] (see below) or file a bug against the
[[https://bugs.launchpad.net/ubuntu-debuginfod][ubuntu-debuginfod project on Launchpad]].

* DONE Novo blog, novos links                               :pt_br:portugues:
CLOSED: [2023-04-20 Thu 21:38]
:PROPERTIES:
:EXPORT_FILE_NAME: novo-blog-novos-links
:END:
Eu sei que não posto aqui há algum tempo, mas gostaria de avisar os
meus leitores (hã!?) de que eu troquei a engine do blog pro [[https://gohugo.io][Hugo]].
Além disso, vocês vão notar que as URLs dos posts mudaram também
(elas não têm mais data, agora são só compostas pelo nome do post; mas
veja abaixo), e que também houve uma mudança na tag =pt_br=:
futuramente eu pretendo parar de postar coisas nela, e vou postar
somente usando a tag [[/tags/portugues][=portugues=]].  Se você acompanha o RSS/ATOM da tag
=pt_br=, por favor atualize o link.

As URLs antigas ainda vão funcionar porque elas estão sendo
redirecionadas pro lugar correto (cortesia do =mod_rewrite=).  De
qualquer modo, se você salvou alguma URL de um post antigo, sugiro que
a atualize.

No mais, tudo deve funcionar "como de costume" (TM).  Estou postando
direto do Emacs (usando [[https://gohugo.io][ox-hugo]]), e criei um setup bacana no [[https://sr.ht][Sourcehut]]
pra automaticamente publicar os posts assim que eu der o push deles
pro git.  Hm, isso na verdade seria um bom tópico pra um post...

* DONE New blog, new links                                    :en_us:english:
CLOSED: [2023-04-20 Thu 21:26]
:PROPERTIES:
:EXPORT_FILE_NAME: new-blog-new-links
:END:
I know I haven't posted in a while, but I'd like to let my readers
(who!?) know that I've switched my blog's engine to [[https://gohugo.io][Hugo]].  Along with
that change, there are also changes to post URLs (no more dates, only
the post name; but see below) and also a change to the =en_us= tag:
eventually, I will stop posting things under it and start posting
solely under [[/tags/english][=english=]].  If you're subscribed to the =en_us= RSS/ATOM
feed, please update it accordingly.

The old URLs should still work because they're being redirected to the
correct path now (thanks, =mod_rewrite=).  Either way, if you have
bookmarked some old post URL I'd suggest that you update it.

Other than that, everything should be "the same" (TM).  I'm posting
from Emacs (using [[https://ox-hugo.scripter.co][ox-hugo]]), and made quite a cool setup with [[https://sr.ht][Sourcehut]]
in order to automatically publish posts when I push them to the git
repo.  Hm, his would actually be a good topic for a post...