Tiempos de "fontanería" (grifos termostáticos y más)

Parece que estamos en esa época del año en la que me toca lidiar con este tipo de cosas, esta vez ha tocado cambiar un grifo de cisterna, cambiar un grifo de bañera por uno monomando y por último "arreglar" un grifo termostático.

Si el finde pasado disfruté de la ducha en la bañera de la aldea luego de haber sustituido el viejo grifo por un monomando que además va a evitar que tiremos agua y hacer que cualquiera pueda cerrarlo, no os quiero contar lo que disfruté de la ducha de hoy luego de llevar una temporada casi escaldándome en la ducha de casa porque el termostático no funcionaba como debiera.

No os voy a mentir, el tema del termostático me tenía un poco acojonadillo porque nunca había desmontado ninguno, este era en una columna de ducha que uso a diario, por lo que si tardaba en conseguir repuestos me quedaba sin servicio en ese baño, en fin... que luego de ver unos videos en youtube explicando como se limpia, como se desmontan por dentro (este se parece bastante al mío) y sobre todo ver en una columna como se saca y que en aliexpress (no se me había ocurrido) hay bastantes modelos genéricos...

Ayer me dispuse a ello, saqué el cartucho, lo desmonté, metí todas las piezas en agua con vinagre al 50% (respetando lo de la media hora máximo para no estropear las juntas) y luego cepillo de dientes y tal para quitar toda la suciedad de 10 años de uso. Luego montar y dar vaselina a todo y probarlo, milagrosamente eso fue todo, ¡funcionaba!

Esta mañana por fin pude darme un ducha un poco fresquita que acompañase al veranillo y tal, no veas como se agradeció el trabajo de ayer y sobre todo lo poco que costó al final eso que me parecía tan difícil, la verdad es que pensaba que lo mínimo iba a ser cambiar el cartucho, pero al final ya véis, con una limpieza.... listo.

Fallos en el rutado de MasMovil y también en su ZTE F680

Desde hace un tiempo soy cliente de la fibra de MasMovil, desde entonces mi router es un ZTE F680 y he venido sufriendo ciertos problemas tanto en la conexión de MasMovil como en el propio router.

Sobre los problemas de MasMovil, se trata de un problema de rutado entre equipos en la red de MasMovil que están fuera de su CGNAT (Carrier Grade NAT), es decir, los que han solicitado tener una IP directa de Internet en su router y no estar detrás de los firewalls de MasMovil.

Entre algunas de estas IPs de MasMovil (no en todas, pero sí entre algunas) se pierde gran parte del tráfico. Por ejemplo, ahora mismo tengo la IP 46.6.0.131 y hace un rato la 46.6.5.195, pues bien, desde estas un ping a 46.6.11.88 o a 46.6.11.223 presenta una pérdida del orden del 90% como se puede ver:
PING 46.6.11.223 (46.6.11.223) 56(84) bytes of data. 64 bytes from 46.6.11.223: icmp_seq=12 ttl=61 time=45.8 ms 64 bytes from 46.6.11.223: icmp_seq=36 ttl=61 time=46.1 ms 64 bytes from 46.6.11.223: icmp_seq=41 ttl=61 time=44.8 ms ^C --- 46.6.11.223 ping statistics --- 45 packets transmitted, 3 received, 93.3333% packet loss, time 998ms rtt min/avg/max/mdev = 44.786/45.542/46.052/0.572 ms He intentado contactar con MasMovil sobre este problema, que evita que podamos hacer una conexión TCP de entre estas IPs de clientes de MasMovil, sin conseguir nada (no conseguí llegar a un nivel de soporte suficientemente alto, sólo se limitaron a comprobar que mi linea estaba bien, cosa que ya sé, no pierdo tráfico contra Inet, sólo contra ciertas IPs de MasMovil).

Por el contrario, el problema del propio router acabo de "solventarlo". En realidad se trata de un workaround, pero vamos, ya estoy contento.

El problema del F680, al menos en las versiones ZTEGF6804P1T6 y ZTEGF6804P1T13 es que cuando defines un port forwarding y luego desde la red interna intentas acceder al puerto redireccionado en la IP externa, la primera vez funciona sin problema, pero la segunda se queda como si se le estuviera haciendo un DROP, y así consecutivamente, es decir, funcionan como la mitad de las conexiones.

La forma que se me ha ocurrido de evitar este problema, que por ejemplo, hacía que no pudiera acceder a mi propia web desde mi propia conexión, es utilizar la DMZ en lugar de hacer un port forwarding, esto es matar moscas a cañonazos, pero al menos no parece causar esos problemas, claro está que deberemos activar firewall en la máquina que pongamos en la DMZ ya que dejará de estar protegida por el firewall del ZTE.

Espero que esto último os ayude a solucionar los problemas que podáis tener con vuestro ZTE F680, yo hasta ahora ha sido el único problema que he tenido, si consiguiera que MasMovil revisase el problema de los rutados y lo solucionase ya sería la monda :-)

061 en Galicia, teléfono equivalente

Sigo sen entender o tema de non dar os teléfonos equivalentes dos números especiais en calquera servicio, así a xente ou a empresa que presta o servicio están suxeitas ós cargos que fagan as operadoras, mentres que se se dan os números equivalentes as chamadas pasan a estar incluídas dentro das tarifas que temos contratadas cos nosos operadores, cun coste normalmente inferior ou gratis.

Un exemplo deste tipo é o teléfono 061, que en Galicia o xestiona a Fundación Pública Urxencias Sanitarias de Galicia que na sua web espefica un formulario de contacto (se non tes presa) e os teléfonos 061 e 902 400 116 como forma de contacto se temos presa, foi precisamente este último teléfono o que me levou á entrada de Danae en no más 900 onde se especifica o 981953400 como número equivalente ó 061 en Galicia, o probei e funciona perfectamente.

En fin... esperemos que pouco a pouco os organismos e empresas que utilizan todavía os 901/2 e outros números especiais vaian dando os equivalentes para poder cortar co negocio este dos números especiais

ScreenLock on Jessie's systemd

Something I was used to and which came as standard on wheezy if you installed acpi-support was screen locking when you where suspending, hibernating, ...

This is something that I still haven't found on Jessie and which somebody had point me to solve via /lib/systemd/system-sleep/whatever hacking, but that didn't seem quite right, so I gave it a look again and this time I was able to add some config files at /etc/systemd and then a script which does what acpi-support used to do before

Edit: Michael Biebl has sugested on my google+ post that this is an ugly hack and that one shouldn't use this solution and instead what we should use are solutions with direct support for logind like desktops with built in support or xss-lock, the reasons for this being ugly are pointed at this bug

Edit (2): I've just done the recommended thing for LXDE but it should be similar for any other desktop or window manager lacking logind integration, you just need to apt-get install xss-lock and then add @xss-lock -- xscreensaver-command --lock to .config/lxsession/LXDE/autostart or do it through lxsession-default-apps on the autostart tab. Oh, btw, you don't need acpid or the acpi-support* packages with this setup, so you can remove them safely and avoid weird things.

The main thing here is this little config file: /etc/systemd/system/screenlock.service

[Unit] Description=Lock X session Before=sleep.target [Service] Type=oneshot ExecStart=/usr/local/sbin/screenlock.sh [Install] WantedBy=sleep.target

This config file is activated by running: systemctl enable screenlock

As you can see that config file calls /usr/local/sbin/screenlock.sh which is this little script:

#!/bin/sh # This depends on acpi-support being installed # and on /etc/systemd/system/screenlock.service # which is enabled with: systemctl enable screenlock test -f /usr/share/acpi-support/state-funcs || exit 0 . /etc/default/acpi-support . /usr/share/acpi-support/power-funcs if [ x$LOCK_SCREEN = xtrue ]; then . /usr/share/acpi-support/screenblank fi

The script of course needs execution permissions. I tend to combine this with my power button making the machine hibernate, which was also easier to do before and which is now done at /etc/systemd/logind.conf (doesn't the name already tell you?) where you have to set: HandlePowerKey=hibernate

And that's all.

Hello Debian Planet and Jessie's question

This was just meant to say hello to the Debian Planet readers, but I'll end it with a Jessie related question, so...

Intro

For those who don't know me, I was born in Betanzos, A Coruña, Galicia, in the North-West of Spain and I currently live on A Coruña. I've been a Debian developer since year 2000 when I was quite more involved than currently (live changes), but I'm always expecting to be able to dedicate more time to the project, I hope this will happen when my two children grow up a little bit.

I had been wanting to send my blog's Debian related posts to the planet but always failed to do so, yesterday I found the planet wiki page and I said... it's so easy that I don't have any excuse not to do it, so here I am.

Oh, BTW... if I ever comment on Debian's anniversary (16th of August) that at Betanzos we are launching a really huge paper balloon, it is not to commemorate Debian's date but in honour of San Roque, even though maybe we should talk to the Pita family to have Debian's logo on it for our 25th anniversary :-)

Jessie's question

In Jessie we no longer have update-notifier-common which had the /etc/kernel/postinst.d/update-notifier script that allowed us to automatically reboot on a kernel update, I have apt-file searched for something similar but I haven't found it, so... who is now responsible of echoing to /var/run/reboot-required.pkgs on a kernel upgrade so that the system reboots itself if we have configured unattended-upgrades to do so?

I really miss this stuff, I don't know if it should be on the kernel, on unattended-upgrades or where, but now that we have whatmaps... we need this feature to round it all.

End

Well, to finish I just want to say that I'm very happy to be a part of the Debian community and that I enjoy reading you guys on the planet. Thanks a lot to all the Debian folks for making Debian not only a great OS, but also a great community.

Hard asterisk times (or how sip made me unhappy till I fixed this peer definition)

It must be that I no longer touch asterisk like I used to do that it took me a while to write a type=peer section this last days.

At my first attempt copying the entry from an old peer definition I was getting a "404 Not Found" message with the asterisk server not even trying to authenticate to the peer when I was trying to make a phone call. I thought it was a problem with my asterisk not wanting to authenticate but it wasn't. What should had happen is that the asterisk should have gotten a "401 Unauthorized" message, and then it would try to authenticate.

After reading a lot I came to the solution by myself comparing asterisk messages with a csipsimple client that I had running, my asterisk was saying something like...

From: "Anonymous" ;tag=xxxx

While the csipsimple client has the server (IP or hostname) specified instead of anonymous.invalid. This first problem was solved with a fromdomain=whateveryourpeerexpects line on the peer definition.

So, I then got the 401 message and the asterisk was trying to authenticate, but this server was expeting to have an authuser on the registration (what is also called the digest username, ...) and even though on asterisk sip.conf doc there are examples on how to use authuser on "register" commands there is none explaining how to do that on a peer definition, I got to a lot of doc explaining how to do that with ways that people was saying that weren't working, patches for asterisk, ... I tested and tested and nothing worked.

I was almost going to go to bed again without fixing this (and it is about time 2AM already) when I started to test things by myself and found that it was defaultuser where I shoud specify this authuser, in fact I had tested this already but it was when I was having the 404 error, so it wouldn't work until I fixed that.

If you read the sip.conf doc, you'll find that:
;defaultuser=yourusername ; Authentication user for outbound proxies
which is quite clear and it's why I had tested it at first, but getting the 404 message made it not work, so in the end my peer looks like this:
[thepeer] type=peer host=thehostip nat=no disallow=all allow=ulaw allow=alaw fromdomain=thehostip defaultuser=theauthuser fromuser=theotheruser secret=thepassword :-)

haproxy as a very very overloaded sslh

After using haproxy at work for some time I realized that it can be configured for a lot of things, for example: it knows about SNI (on ssl is the method we use to know what host the client is trying to reach so that we know what certificate to present and thus we can multiplex several virtual hosts on the same ssl IP:port) and it also knows how to make transparent proxy connections (the connections go through haproxy but the ending server will think they are arriving directly from the client, as it will see the client's IP as the source IP of the packages).

With this two little features, which are available on haproxy 1.5 (Jessie's version has them all), I thought I could give it a try to substitute sslh with haproxy giving me a lot of possibilities that sslh cannot do.

Having this in mind I thought I could multiplex several ssl services, not only https but also openvpn or similar, on the 443 port and also allow this services to arrive transparently to the final server. Thus what I wanted was not to mimic sslh (which can be done with haproxy) but to get the semantic I needed, which is similar to sslh but with more power and with a little different behaviour, cause I liked it that way.

There is however one caveat that I don't like about this setup and it is that to achieve the transparency one has to run haproxy as root, which is not really something one likes :-( so, having transparency is great, but we'll be taking some risks here which I personally don't like, to me it isn't worth it.

Anyway, here is the setup, it basically consists of a setup on haproxy but if we want transparency we'll have to add to it a routing and iptables setup, I'll describe here the whole setup

Here is what you need to define on /etc/haproxy/haproxy.cfg:

frontend ft_ssl bind 192.168.0.1:443 mode tcp option tcplog tcp-request inspect-delay 5s tcp-request content accept if { req_ssl_hello_type 1 } acl sslvpn req_ssl_sni -i vpn.example.net use_backend bk_sslvpn if sslvpn use_backend bk_web if { req_ssl_sni -m found } default_backend bk_ssh backend bk_sslvpn mode tcp source 0.0.0.0 usesrc clientip server srvvpn vpnserver:1194 backend bk_web mode tcp source 0.0.0.0 usesrc clientip server srvhttps webserver:443 backend bk_ssh mode tcp source 0.0.0.0 usesrc clientip server srvssh sshserver:22

An example of a transparent setup can be found here but lacks some details, for example, if you need to redirect the traffic to the local haproxy you'll want to use the xt_TPROXY, there is a better doc for that at squid's wiki. Anyway, if you are playing just with your own machine, like we typically do with sslh, you won't need the TPROXY power, as packets will come straight to your 443, so haproxy will be able to get the without any problem. The problem will come if you are using transparency (source 0.0.0.0 usesrc clientip) because then packets coming out of haproxy will be carrying the ip of the real client, and thus the answers of the backend will go to that client (but with different ports and other tcp data), so it will not work. We'll have to get those packets back to haproxy, for that what we'll do is mark the packages with iptables and then route them to the loopback interface using advanced routing. This is where all the examples will tell you to use iptables' mangle table with rules marking on PREROUTING but that won't work out if you are having all the setup (frontend and backends) in just one box, instead you'll have to write those rules to work on the OUTPUT chain of the mangle table, having something like this:

*mangle :PREROUTING ACCEPT :INPUT ACCEPT :FORWARD ACCEPT :OUTPUT ACCEPT :POSTROUTING ACCEPT :DIVERT - -A OUTPUT -s public_ip -p tcp --sport 22 -o public_iface -j DIVERT -A OUTPUT -s public_ip -p tcp --sport 443 -o public_iface -j DIVERT -A OUTPUT -s public_ip -p tcp --sport 1194 -o public_iface -j DIVERT -A DIVERT -j MARK --set-mark 1 -A DIVERT -j ACCEPT COMMIT

Take that just as an example, better suggestions on how to know what traffic to send to DIVERT are welcome. The point here is that if you are sending the service to some other box you can do it on PREROUTIING, but if you are sending the service to the very same box of haproxy you'll have to mark the packages on the OUTPUT chain.

Once we have the packets marked we just need to route them, something like this will work out perfectly:

ip rule add fwmark 1 lookup 100 ip route add local 0.0.0.0/0 dev lo table 100

And that's all for this crazy setup. Of course, if, like me, you don't like the root implication of the transparent setup, you can remove the "source 0.0.0.0 usesrc clientip" lines on the backends and forget about transparency (connections to the backend will come from your local IP), but you'll be able to run haproxy with dropped privileges and you'll just need the plain haproxy.cfg setup and not the weird iptables and advanced routing setup.

Hope you like the article, btw, I'd like to point out the main difference of this setup vs sslh, it is that I'm only sending the packages to the ssl providers if the client is sending SNI info, otherwise I'm sending them to the ssh server, while sslh will send ssl clients without SNI also to the ssl provider. If your setup mimics sslh and you want to comment on it, feel free to do it.