Não, #Lidl e #SilverCrest, depois de vender vocês não mandam…

Caros Lidl e SilverCrest,

Gostei muito dos auscultadores que comprei esta semana na vossa loja mas fiquei a-bis-ma-do com a vossa falta de vergonha e muita lata:

Condições de utilização

«Os auscultadores só podem ser utilizados para uso privado, e não com fins industriais ou comerciais

O quê? Mas a que propósito se acham sequer com coragem de declarar isto? É vergonhoso que achem isto correto!

Depois desta falta de vergonha, ainda têm a distinta lata de terminar com a seguinte frase ao virar a página, na mesma secção:

«Deve respeitar as leis e os regulamentos nacionais do país de utilização.»

Olha, ninguém quererá mesmo saber disto, eu por mim estou só a dar um desabafo e vocês, Lidl e SilverCrest, seguramente nem querem saber.

A verdade é que eu estou satisfeito com o produto e vocês ficaram satisfeitos com o dinheiro.

Só não dou o devido uso a este papel porque prefiro algo muito mais fofinho, está bem? 🙂

I retired some pants, thanks to #keto

After having passed yesterday feeling always very worried my pants would fall off, I did a most needed check on pant sizes.

7 were retired for being too big to use, even with a belt
4 I can still use, with a belt
2 perfect fits (and boy did I miss these two 501’s)
3 that are still a bit too tight to feel comfortable

This means I should consider buying a few transitional cheap pants in a couple of months,  on the sales period.

All this I achieved by keeping myself quite faithful to a ketogenic diet.

No more staples!

I was told in follow-up that I’d be having some of the staples removed today, but things looked so good that all of them were removed!

Staples, after removal

In a few days, the remaining stitches will also be removed.

Got rid of a plugin!

In WordPress , it’s not so much the CMS or PHP that’s usually the problem but most frequently plugins.

So whenever one can get rid of a plugin, it’s always a cause for celebration.

Yay, for I now use WordPress’s native galleries!

I’ve had surgery #hospitalporn

Back in May 29th I woke up fresh, well humoured, proceeded to have a shower and just afterwards, as I dried myself, in a matter of naught but a couple of seconds I thought an explosion had gone off in my head, the strongest headache I ever felt fired up and left me unable to do anything, having to wake up my family to take me to the big H, fearing the worse (stroke, or something worse entirely).

This post will have some gore imagery but it won’t be automatically displayed, you’ll have to click the images in order to view them. It was so traumatic to me that I need to do this as a sort of catharsis.

WARNING: it is long, and it’s mean, and VIEWER DISCRETION IS ADVISED.

Continue reading “I’ve had surgery #hospitalporn”

Simple experiment with systemd-networkd and systemd-resolved

In my previous post, I wrote about how simple it was to create containers with systemd-nspawn.

But what if you wanted to expose to the outside network to a container? The rest of the world can’t add mymachines to /etc/nsswitch.conf and expect it to work, right?

And what if you were trying to reduce the installed dependencies in an operating system using systemd?

Enter systemd-networkd and systemd-resolved

Firstly, this Fedora 25 host is a kvm guest so I added a new network interface for “service” were I created the bridge (yes, with nmcli, why not learn it as well on the way?)

nmcli con add type bridge con-name Containers ifname Containers
nmcli con add type ethernet con-name br-slave-1 ifname ens8 master Containers
nmcli con up Containers

Then, in container test, I configured a rule to use DHCP (and left in a modicum of a template for static addresses, no… that’s not my network) and replaced /etc/resolve.conf with a symlink to the file systemd-resolved manages:

cat <<EOF > /etc/systemd/network/20-default.network

# or swap the above line by the lines below:

rm /etc/resolv.conf
ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf

Finally, I enabled and started networkd and resolved:

systemctl enable systemd-networkd
systemctl enable systemd-resolved
systemctl start systemd-networkd
systemctl start systemd-resolved

A few seconds later…

-bash-4.3# ip addr list dev host0
2: host0@if29: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state LOWERLAYERDOWN group default qlen 1000
 link/ether 06:14:9c:9e:ac:ca brd ff:ff:ff:ff:ff:ff link-netnsid 0
 inet brd scope global host0
 valid_lft forever preferred_lft forever

-bash-4.3# cat /etc/resolv.conf 
# This file is managed by systemd-resolved(8). Do not edit.
# This is a dynamic resolv.conf file for connecting local clients directly to
# all known DNS servers.
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
# See systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.


Happy hacking!

Simple experiment with systemd-nspawn containers

For this test I used Fedora 25. Your mileage might vary in other operating systems, some things may be the same, some may not be.

WARNING: you’ll need to disable selinux so to me this was merely an interesting experiment and it lead to increasing my knowledge, specially in relation to selinux + containers. Bad mix, no security, containers don’t contain, etc.

Many thanks to the nice people from #fedora and #selinux that graciously lent their time to help me when I was trying to use nspawn with selinux enabled. With their help, specially Grift from #selinux, we were actually able to run it, but only in a way I’m so uncomfortable with that I ultimately considered this experiment to  be a #fail as I’m definitely not going to use them like that any time soon: there’s still a lot of work to do in order to run containers with some security. I hope the Docker infatuation leads to an universal solution towards security + containers from the good engineers at Red Hat and others involved in that work.

But it certainly was a success in terms of contributing to more experience beyond a quickly expiring benefit of familiarity with OpenVZ.

Enough words, here’s how simply it was…

Firstly, let’s setup a template from which we’re going to copy to new instances. As I’m using Fedora 25, I used DNF’s capability to install under a directory:

dnf --releasever=25 \
 --installroot=/var/lib/machines/template-fedora-25 \
 -y install systemd passwd dnf fedora-release \
 iproute less vi procps-ng tcpdump iputils

You’ll only need the first three lines, though, the fourth was just a few more packaged I preferred to have in my template.

Secondly, you’ll probably like to do further customization in your template, so you’ll enter your container just like it was (well, is) an enhanced chroot:

cd /var/lib/machines
systemd-nspawn -D template-fedora-25

Now we have a console, and the sky is the limit for what you can setup, like for instance defining a default pasword for root with passwd (but maybe you’ll not want to do this in a production environment).

For some weird reason, passwd constantly failed manipulating authentication tokens, but I solved it quickly by merely reinstalling passwd (dnf -y reinstall passwd). Meh…

I also ran dnf -y clean all before exiting the container in order to clean up unnecessary space wasted with package meta data that will be expired quickly.

When you’re done customizing, exit the container with ctrl + ]]] in about a second.

Finally, we’re ready to preserve the template:

cd template-fedora-25
tar --selinux --acls --xattrs czvf \
    ../$(basename $( pwd ) )-$(date +%Y%m%d).tar.gz .
cd ..

We’re now ready to create a test container and launch it in the background:

mkdir test
cd test
tar --selinux --acls -xattrs xzvf \
cd ..
machinectl start test

This container will probably not be able to run services exposed outside without help but you can login into its console with machinectl login test

You’ll also have automagic name resolution from your host computer to the containers it runs if you change the hosts entry in /etc/nsswitch.conf placing mymachines between files and dns (or as you see fit if otherwise in your setup):

hosts: files mymachines dns myhostname

If you had enable ssh in your container, you’d be able to do ssh test from the host machine. Or access a web server you installed in it. Who knows.

As you saw, despite a lot of words trying to explain every step of the way, it’s excruciatingly simple.

The next article (Simple experiment with systemd-networkd and systemd-resolved) expands this example with a bridge in the host machine in order to allow your containers to talk directly with the external world.

Happy hacking!