Fedora
[Spanish] MTProxy on Fedora/CentOS Stream/RHEL
While I usually for no specific reason write in English, this post is written in Spanish due to the absurd precautionary measure of blocking Telegram.
Si vais a usar Ubuntu, esta guia es genial, además incluye alguna cosa como registrar el proxy que yo he obviado a proposito.
Hay muchas formas de saltarse un bloqueo a Telegram. Desde cambiar los DNS, hasta usar una VPN pero, en mi opinión, la mejor es MTProxy. Aunque el proyecto parece parado desde hace unos años, todavía funciona y para salir de un apuro, es una solución ideal.
Todavía no se sabe como van a bloquear el uso de la plataforma (aunque viendo como se ha hecho hasta ahora este tipo de cosas, van a bloquear los dominios con casi total seguridad). Si este es el caso, yo personalmente uso NextDNS para bloquear ciertas páginas.
Sin embargo, cambiar los DNS no me parece una medida adecuada de cara a seguir usando Telegram. No siempre es factible cambiarlos. Algunos routers suministrados por proveedores de servidores de Internet no permiten hacer estas modificaciones.
¿Y una VPN? Esta solución es un poco drástica. Por funcionar, funciona. Pero, salvo que sepas lo que estas haciendo, estarías pasando todo el trafico del dispositivo por la VPN. E igual no es algo que te interesa. Igual no quieres estar saliendo por Francia las 24 horas del dia. O igual no puedes tener todos tus dispositivos en una VPN como por ejemplo el ordenador del trabajo. Además de que los servicios de VPN son de dudosa fiabilidad. Si vas a seguir esta ruta, mi recomendación es que te montes tu mismo la VPN, ya sea usando OpenVPN o WireGuard, o que uses un servicio por el que estás pagando y del que te fías. Yo personalmente uso la primera opción pero ProtonVPN me ha dado buen resultado en el pasado.
¿Por qué un proxy y en particular MTProxy? Pues bastante sencillo. Telegram soporta esto de manera nativa en todas las aplicaciones oficiales. Soporta SOCKS5 y MTProto y una vez tengas montado el servicio, puedes compartir el enlace con la gente que te importa. El tráfico de Telegram es lo único que va a través del proxy, no afectando en absoluto a la conexión del resto de aplicaciones del dispositivo.
Así que si tienes una máquina con Fedora, CentOS Stream 9 o RHEL 9 (puede que funcione con versiones anteriores pero no lo he probado), sigue estos pasos. Yo por el momento uso Linode y un servidor en Amsterdam. El proveedor de la maquina virtual es lo de menos. Asegúrate también de que sabes como proteger y mantener un equipo expuesto públicamente.
Se asume que la máquina esta limpia, si es una máquina que ya tenias, puede que los pasos del firewall te den problemas. Pero si ya tienes una máquina es que sabes lo que haces :)
Vamos a rodar todas las instrucciones como root y están muy basadas en lo que dice la propia documentación, con algunos pequeños cambios para ponerla al día. El servicio no va a estar rodando como root, tranquilo :P
Vamos a instalar las dependencias que necesitamos para compilar MTProxy.
dnf install openssl-devel zlib-devel
dnf groupinstall "Development tools"
Ahora necesitamos bajar el proyecto.
git clone https://github.com/TelegramMessenger/MTProxy
cd MTProxy
Hay un problema actualmente en MTProxy si intentamos compilarlo, hace un tiempo un usuario abrió una pull request con la solución, así que vamos a aplicar su parche:
curl -L -O https://patch-diff.githubusercontent.com/raw/TelegramMessenger/MTProxy/pull/531.patch
git am 531.patch
rm -f 531.patch
Para compilarlo, solo tenemos que hacer:
make
Puede que durante la compilación veas algunos warnings, y como cualquier buena instalación, vamos a obviarlos :P (En CentOS Stream 9 no los he visto pero si en Fedora 39, así que puede que se deba a diferentes ajustes en GCC, no le he dedicado mucho tiempo a esto).
En general, una aplicación instalada a mano suele ponerse en /opt y ahí es donde vamos a ponerla (lee man hier si tienes curiosidad).
mkdir /opt/MTProxy
cp objs/bin/mtproto-proxy /opt/MTProxy/
cd /opt/MTProxy/
Ahora tenemos que hacernos con el secreto y la configuración que nos da Telegram. La configuración puede cambiar así que aconsejan renovarla a diario (candidato ideal para un cron :))
curl -s https://core.telegram.org/getProxySecret -o proxy-secret
curl -s https://core.telegram.org/getProxyConfig -o proxy-multi.conf
El contenido de /opt/MTProxy debería ser: mtproto-proxy, proxy-multi.conf y proxy-secret.
Ahora necesitamos el secreto que usaremos para validar nuestros clientes contra nuestro servidor. Puede ser cualquier cosa que te inventes, pero lo que sugiere el proyecto es ideal: simplemente guarda en algún lado la salida de esta instrucción:
head -c 16 /dev/urandom | xxd -ps
Necesitamos asegurarnos de que el firewall que suele venir activado de serie no nos de problemas.
firewall-cmd --permanent --new-service=MTProxy
firewall-cmd --permanent --service=MTProxy --add-port=4242/tcp
firewall-cmd --permanent --add-service=MTProxy
firewall-cmd --reload
Si todo ha ido bien, deberías haber visto varios success. Pero siempre puedes comprobar que MTProxy esta listo en el el firewall con:
firewall-cmd --list-all | grep services
Aunque ya tenemos todo lo que necesitamos, la guinda en el pastel es configurar MTProxy como servicio que ruede como un usuario no privilegiado sin shell y sin home.
Primero creamos el usuario, y le damos permisos sobre /opt/MTProxy.
useradd -M -s /sbin/nologin mtproxy
chown -R mtproxy:mtproxy /opt/MTProxy
Ahora, necesitamos crear el servicio. Fíjate que necesitas modificar las lineas un poco para incluir el secreto que generamos antes de pegarlo en la terminal.
cat <<EOF > /etc/systemd/system/MTProxy.service
[Unit]
Description=MTProxy
After=network.target
[Service]
Type=simple
User=mtproxy
Group=mtproxy
WorkingDirectory=/opt/MTProxy
ExecStart=/opt/MTProxy/mtproto-proxy -H 4242 -S <EL SECRETO VA AQUI> --aes-pwd proxy-secret proxy-multi.conf --log mtproxy.log -M 1
Restart=on-failure
[Install]
WantedBy=multi-user.target
EOF
Tras esto, ya estamos listos para rodar el servicio:
systemctl daemon-reload
systemctl enable MTProxy.service
systemctl start MTProxy.service
systemctl status MTProxy.service
Para configurarlo fácilmente, adapta el siguiente enlace, o compártelo a quien quieras:
https://t.me/proxy?server=<LA IP PUBLICA>&port=<EL PUERTO>&secret=<EL SECRETO>
Si encuentras algún fallo, por favor, dímelo para que pueda actualizarlo.
Go 1.21 in Fedora 38
Fedora 38 will have Go 1.21 until its EOL (2024-05-14). FESCo approved the change, and it was announced few days ago. The update is on testing and unless something happens it will be push soon. Feel free to test it and give karma if everything works for you.
By the way, this doesn’t mean there will be a mass rebuild of everything in Fedora 38 to use Go 1.21. Only new updates will use it. This is the third time we do this kind of update to avoid having an unsupported version in Fedora for weeks.
And, just a reminder that if you want the latest Go releases, you can always enable the golang-rawhide COPR project that I maintain.
Go 1.22 in Fedora 40
If everything goes as planned, Fedora 40 will have Go 1.22.
Go 1.22 is planned for February 2024, and Fedora 40 around April 2024.
I’ve been doing the Go updates for the past few releases since Go 1.15 in Fedora 33. ~3 years!
I just created the wiki page for the proposal. The email thread in the Development list will land soon.
And if you are curious, the ongoing PR is here. So far, it has been easy peasy, with no problems at all (knock on wood). I like to use pull request for all my changes, (we are a lot of people making Fedora possible and it brings clarity in the intentions), but for yet-to-be-accepted changes is mandatory, Rawhide won’t have Go 1.22 until is approved by FESCo.
On a side note, there is an ongoing conversation about some defaults we ship in Fedora. In my opinion, the discussion is worth reading (and not because I started it 😅). Participate, please! It’s a small change but quite relevant for the Go users.
Bundling Delve on Fedora
TL;DR: Delve now has bundle dependencies.
While working on integrating Delve with Packit, I found myself trying to fix some dependencies again. This is not usually a problem, but in some packages, like Delve, the version of the already existing Fedora packages containing the dependencies doesn’t match. Patching tests to adapt them to a different version when the upstream project is active and well-tested sounds like a bad idea. So, I bundled the dependencies.
This should make the whole update process for Delve really straightforward and almost automagic because Packit will detect new versions and open the PR for every supported branch.
By the way, I created a Fedora category and added myself to Fedora Planet.
Testing Fedora packages in Toolbox
This is just the usual Fedora testing workflow but with a container in the middle, so nothing really relevant, to be honest.
I made a massive mistake in the Fedora release process a few Go minor releases ago (around 1.16.1, I think). Basically, the Go package was stuck in the previous version.
So now that I’m making another two releases (1.15.12 for Fedora 33 and 1.16.4 for Fedora 34 and Rawhide), I wondered how I can try my ready-to-be-published version in a container.
Yes, I participate in the Fedora community but I never tested a package. Shame on me.
The release
First of all, let’s check what is included in Go 1.15.12 by looking at
the upstream milestone.
At some point in the release process, we’ll need to specify if we solve something
with this release already tracked in the Fedora bug tracker.
/me looks bugs and reads comments…
Alright! It looks like we only have issue 45711 which seems to be bug 1958343.
Well, I guess we can start the release process:
# Clone the fedora repository
fedpkg clone golang && cd golang
# Switch to the target release
fedpkg switch-branch f33
# Bump up the version
rpmdev-bumpspec golang.spec
# 99.999% of the time we'll need to edit the golang.spec
vim golang.spec
# Let's download the upstream sources
spectool -g golang.spec
# Include them in the Fedora cache
fedpkg new-sources go1.15.12.src.tar.gz
# Commit the changes
git add -A && git commit -m "Update to go1.15.12"
# Perform a scratch build before submiting the code
fedpkg scratch-build --srpm
# Wait...
git push
# The real build
fedpkg build
# After a while we can do the release with the information of the bug
fedpkg update
A quick summary of what we have:
The testing
Now that our release is on testing, we can create a container, subscribe to that testing channel, and see if I screwed it again :). And this is an excellent excuse to use Toolbox.
toolbox create --release 33
toolbox enter --container fedora-toolbox-33
Now we should be inside a container. A nice thing about Toolbox is that we don’t have any of the packages installed on the host, just those that came with the image. Still, we have access to all of our configurations and files. Pretty neat to test stuff, isn’t it?
We can install Go, check the version, and then, once the package we submitted reaches the testing state, update it by using the updates-testing repository:
# First we need the stable package
sudo yum install golang
# Output: go version go1.15.11 linux/amd64
go version
# The magic trick
sudo dnf upgrade --enablerepo=updates-testing golang
# Output: go version go1.15.12 linux/amd64
go version
If you use VSCode, you can now jump into the container using
Attach to Running Container.
If you are interested in helping out the Fedora community, feel free to read the wiki, and if you don’t have spare machines to try new and potentially unstable stuff, you can use this container approach with a lot of different packages (forget about kernel testing for example) or swap the container for a VM.
Happy testing :)