From d7a33df68a32962c4a249ca2fa523bbe3a7778d2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?O=CC=81scar=20M=2E=20Lage?= Date: Mon, 7 Mar 2022 23:06:37 +0100 Subject: [PATCH] Update: Some posts has now hilighted code --- .../posts/bash-ps1-and-long-commands/index.md | 2 +- .../bucles-asincronos-en-javascript/index.md | 4 ++-- .../posts/docker-all-the-things/index.md | 2 +- .../posts/irssi-hilighting-your-nick/index.md | 4 ++-- .../index.md | 8 +++---- .../mattermost-and-matterbridge/index.md | 6 ++--- .../index.md | 24 +++++++++---------- src/content/posts/vim-tmux-and-vimux/index.md | 2 +- 8 files changed, 26 insertions(+), 26 deletions(-) diff --git a/src/content/posts/bash-ps1-and-long-commands/index.md b/src/content/posts/bash-ps1-and-long-commands/index.md index e0094b3..f269616 100644 --- a/src/content/posts/bash-ps1-and-long-commands/index.md +++ b/src/content/posts/bash-ps1-and-long-commands/index.md @@ -12,7 +12,7 @@ image: bash-ps1-and-long-commands00.jpg

In my case it was exactly like that:

-``` +```sh export PS1="033[1;30m]» [e[0;33m]mbp033[1;30m]╺─╸[033[1;30m][[033[0m]W[033[1;30m]][033[1;34m]:[033[0m] " export PS1="[033[1;30m]» [e[0;33m]mbp[033[1;30m]╺─╸[033[1;30m][[033[0m]W[033[1;30m]][033[1;34m]:[033[0m] " ``` diff --git a/src/content/posts/bucles-asincronos-en-javascript/index.md b/src/content/posts/bucles-asincronos-en-javascript/index.md index 6f4d00b..b6e2178 100644 --- a/src/content/posts/bucles-asincronos-en-javascript/index.md +++ b/src/content/posts/bucles-asincronos-en-javascript/index.md @@ -13,7 +13,7 @@ image: vuedotjs.jpg

Tengo que definir el método como asíncrono para poder hacer que unas peticiones esperen por el resultado de la anterior, hasta donde he leído ningún problema por definir async mounted() y jugar con await y Promises, pero ¿qué opináis de esa tercera llamada en bucle?.

Entiendo que si dentro del bucle forEach de rounds defino el método como asíncrono podré hacer las llamadas correspondientes esperando su ejecución con await, tal que así:

-``` +```js Array.from(this.rounds).forEach( async round => { await this.get_competitors_list(round.round_id); [...] @@ -22,7 +22,7 @@ Array.from(this.rounds).forEach( async round => {

Error, forEach no va a esperar a que hayan acabado los elementos marcados como tal, simplemente ejecuta y sigue. Así que, leyendo un poco de Iteration protocols veo que en su lugar podemos usar for..of, que es una versión moderna del "for loop" de forma que, simplemente cambiando forEach y adaptando la sintaxis al nuevo bucle haremos que funcione adecuadamente:

-``` +```js for(let round of this.rounds) { await this.get_competitors_list(round.round_id); [...] diff --git a/src/content/posts/docker-all-the-things/index.md b/src/content/posts/docker-all-the-things/index.md index 3b11b54..71771b5 100644 --- a/src/content/posts/docker-all-the-things/index.md +++ b/src/content/posts/docker-all-the-things/index.md @@ -12,7 +12,7 @@ image: docker-all-the-things.jpg

Este 2019 ha venido con múltiples sorpresas a nivel laboral, variopintos proyectos, cada uno con su stack y sus requisitos distintos. Diferentes lenguajes de programación, diferentes maneras de guardar los datos pero todos ellos con un denominador común: una carretilla llena de problemas a la hora de montar el entorno de desarrollo.

Tengo proyectos con MySQL-5.5, con MySQL-5.7, MariaDB-10.1.32, AuroraDB, Python-2.7, Python-3.6.5, Django, Flask, FalconFramework, Zappa, PHP-5.6, PHP-7.*, CodeIgniter, Laravel, Apache2.2, Apache2.4, Nginx, Jasper Reports... Imaginaos por un momento que no exista ningún tipo de solución de virtualización barra containers barra whatever. ¡La que se podría haber liado para montar todo esto!. El ejemplo más llamativo de los últimos días ha sido la dependencia de un Jasper Server, con todo su JAVATomcat y demás dolores de cabeza... Y por otro lado tendríamos algo tal que así:

-``` +```sh $ docker pull bitnami/bitnami-docker-jasperreports $ vim docker-compose.yml ... diff --git a/src/content/posts/irssi-hilighting-your-nick/index.md b/src/content/posts/irssi-hilighting-your-nick/index.md index 4c46f93..02a3db4 100644 --- a/src/content/posts/irssi-hilighting-your-nick/index.md +++ b/src/content/posts/irssi-hilighting-your-nick/index.md @@ -12,13 +12,13 @@ image: irssi-hilighting-your-nick.jpg

What was the problem then? It seems that irssi was highlighting only when someone mentioned me at the beginning of the phrase like this r0sk: but it wasn't doing it in a normal nick mention in the middle of a sentence like hey r0sk sup there!? or similar.

I knew that something like this could be configured so reading a bit about irssi hilight found the way to be alerted even if they are shouting r000ssskkk!! to me, the solution can be applied in two ways, in the irssi command line:

-``` +```sh /hilight -regexp r0+s+k+ ```

And, of course, in the .irssi/config file, because if you have put it in the command line and the setting is not saved to the config file, it won't work in case of restart:

-``` +```python hilights = ( { text = "r0+s+k+"; nick = "yes"; word = "yes"; regexp = "yes"; } ) diff --git a/src/content/posts/lets-encrypts-root-certificate-expired/index.md b/src/content/posts/lets-encrypts-root-certificate-expired/index.md index 2e33e5e..328d3fb 100644 --- a/src/content/posts/lets-encrypts-root-certificate-expired/index.md +++ b/src/content/posts/lets-encrypts-root-certificate-expired/index.md @@ -10,7 +10,7 @@ image: letsencrypt.png

In my case I've a Debian7 using and comsuming some LE certs in both ways so I woke up this morning with the smell of alert in the atmosphere. After reading some literature here and there and talked about it with some mates, decided to manually update the certificate. I was forced to proceed in that way because the package updates for deb7 are totally out of date (or even closed I'd say).

We can see the error here:

-``` +```bash $ openssl s_client -host oscarmlage.com -port 443 -showcerts CONNECTED(00000003) depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1 @@ -28,13 +28,13 @@ verify return:0

Now that we already have them handy, we need to copy the good one, remove the older other in the affected machine and refresh the certificates:

-``` +```bash $ scp user@newerhost:/usr/share/ca-certificates/mozilla/ISRG_Root_X1.crt /usr/share/ca-certificates/mozilla/ $ mv /usr/share/ca-certificates/mozilla/DST_Root_CA_X3.crt /tmp/ ``` -``` +```bash $ echo "/usr/share/ca-certificates/mozilla/ISRG_Root_X1.crt" >> /etc/ca-certificates.conf $ vim /etc/ca-certificates.conf # remove the /usr/share/ca-certificates/mozilla/DST_Root_CA_X3.crt line @@ -46,7 +46,7 @@ Running hooks in /etc/ca-certificates/update.d....done.

And we can test if it works now:

-``` +```bash $ openssl s_client -host oscarmlage.com -port 443 -showcerts CONNECTED(00000003) depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1 diff --git a/src/content/posts/mattermost-and-matterbridge/index.md b/src/content/posts/mattermost-and-matterbridge/index.md index 5d70c52..e9be1f9 100644 --- a/src/content/posts/mattermost-and-matterbridge/index.md +++ b/src/content/posts/mattermost-and-matterbridge/index.md @@ -31,7 +31,7 @@ image: mattermost-matterbridge.JPG

Install a Mattermost server

As slackers, laziness is the strength that moves us so we are going to use docker for both (mattermost and matterbridge) directly in command line (we should prepare our database before, I told you I was old-school so I don't go for a db-container this time):

-``` +```bash docker run -d -p 8000:8000 -e MM_SERVICESETTINGS_SITEURL="<https://mymattermost.domain.com>" @@ -54,7 +54,7 @@ docker run -d

Install Matterbridge

For installing matterbridge we should have a configuration file that says to the binary where to connect and what to do with the messages, so first of all we will create our matterbridge.toml file:

-``` +```bash [irc] [irc.freenode] Server="irc.freenode.net:6667" @@ -88,7 +88,7 @@ enable=true

So, it's time to run the bridge:

-``` +```bash docker run -d -v /home/docker/matterbridge/matterbridge.toml:/matterbridge.toml -h matterbridge01 diff --git a/src/content/posts/por-mi-y-por-todos-mis-companeros/index.md b/src/content/posts/por-mi-y-por-todos-mis-companeros/index.md index 1c87e5b..f040ba3 100644 --- a/src/content/posts/por-mi-y-por-todos-mis-companeros/index.md +++ b/src/content/posts/por-mi-y-por-todos-mis-companeros/index.md @@ -11,23 +11,23 @@ image: IMG_20181109_090634_Bokeh.jpg

¿Por qué?, porque hace algún tiempo, en las instalaciones por defecto, la partición con mayor tamaño era esa, así que lo pedía a gritos. Y hasta el momento no he cambiado porque todos los scripts de deploy, provisionamiento y demás están prepardos para ello. Vagancia.

Estos últimos días he tenido un problema que nunca me había pasado antes con un servidor. En este caso, inicialmente no había separación de particiones y todo estaba montado en /, pero ante la falta de espacio se contrató un disco a mayores con la idea de montarlo en /home de forma separada y mover el grueso de la información ahí dentro:

-``` -# mkfs.ext4 /dev/sdb1 -# mkdir /home2 -# mount /dev/sdb1 /home2 -# rsync -az /home/ /home2/ -# umount /home2 -# mount /dev/sdb1 /home +```sh +$ mkfs.ext4 /dev/sdb1 +$ mkdir /home2 +$ mount /dev/sdb1 /home2 +$ rsync -az /home/ /home2/ +$ umount /home2 +$ mount /dev/sdb1 /home ```

Creamos la partición del nuevo dispositivo, la montamos como /home2, sincronizamos datos, desmontamos /home2 y la montamos de nuevo como /home. Hasta aquí todo correcto ¿no?. Pues no. Si el antiguo /home no se borra queda ahí consumiendo espacio y - lo más gracioso - como posteriormente montamos /dev/sdb1 como /home, queda oculto.

Así que, cuando vayas a mirar por qué sigue quedándose / sin espacio habiendo descargado todo "lo gordo" te podrá pasar como a mí y perder 3 horas de research con du, df, scripts en bash, lsof y demás. O quizás seas un poco más avispado y te des cuenta. Solución:

-``` -# mv /home /home_old -# mount /dev/sdb1 /home -# echo "Comprueba que todo funciona, varias veces, y posteriormente:" -# rm -rf /home_old +```sh +$ mv /home /home_old +$ mount /dev/sdb1 /home +$ echo "Comprueba que todo funciona, varias veces, y posteriormente:" +$ rm -rf /home_old ```

Moraleja: nunca juegues al escondite con tus sistemas. Y menos si eres tú el que pone unas normas que luego no recuerdas.

diff --git a/src/content/posts/vim-tmux-and-vimux/index.md b/src/content/posts/vim-tmux-and-vimux/index.md index 3450c72..921c018 100644 --- a/src/content/posts/vim-tmux-and-vimux/index.md +++ b/src/content/posts/vim-tmux-and-vimux/index.md @@ -12,7 +12,7 @@ image: tmux-vim-vimux.png

tmux, vim, vimux

You can Vimux and it just opens a tmux pane (or window), execute the command you want, and go back to vim. The configuration I wrote (~/.vimrc):

-``` +```vim "--------------------------------------------------------- "------------- Vimux "---------------------------------------------------------