sergiodj/blog
1
0
Fork 0
Code Releases Activity Actions

Fix code highlighting on all posts

Browse source
This commit is contained in:
Sergio Durigan Junior 2024-02-25 16:07:05 -05:00
parent 0171106eee
commit cb2a0bcfff
10 changed files with 299 additions and 261 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
content/posts/debuginfod-for-debian.md
View file

@ -96,7 +96,7 @@ consumed by GDB nor `debuginfod` (for a good example of a distribution
that does that, see Fedora's `debugsource` packages). Let me show you
an example of debugging GDB itself (using `debuginfod`) on Debian:
```
```console
$ HOME=/tmp DEBUGINFOD_URLS=https://debuginfod.debian.net gdb -q gdb
Reading symbols from gdb...
Downloading separate debug info for /tmp/gdb...
@ -176,7 +176,7 @@ package. Notice that the last directory's name in both paths is the
same, so in this case we can use GDB's `set substitute-path` command
do the job for us (in this example `$PWD` is `/tmp/`):
```
```console
$ HOME=/tmp DEBUGINFOD_URLS=https://debuginfod.debian.net gdb -q gdb
Reading symbols from gdb...
Reading symbols from /tmp/.cache/debuginfod_client/02046bac4352940d19d9164bab73b2f5cefc8c73/debuginfo...
@ -224,7 +224,7 @@ whether she wants to use our service by default.
If you would like to start using the service right now, all you have
to do is set the following environment variable in your shell:
```
```bash
DEBUGINFOD_URLS="https://debuginfod.debian.net"
```

53
content/posts/fedora-on-acer-c720p.md
View file

@ -122,8 +122,9 @@ We're almost there! The last step before you boot your Fedora LiveUSB is
to actually enable SeaBIOS. Just go inside your superuser shell (from
the previous step) and type:
#!bash
> crossystem dev_boot_usb=1 dev_boot_legacy=1
```console
> crossystem dev_boot_usb=1 dev_boot_legacy=1
```
And that's it!
@ -149,8 +150,9 @@ You can solve that by passing the `mem` parameter to Linux. So, when
GRUB complains that it was unable to load the specified image, it will
give you a command prompt (`boot:`), and you just need to type:
#!bash
boot: linux mem=1980M
```console
boot: linux mem=1980M
```
And that's it, things should work.
@ -220,16 +222,18 @@ bug](https://bugzilla.redhat.com/show_bug.cgi?id=1045821#c63)), I found
out about a few Linux flags that I could provide in boot time. To save
you time, this is what I have now in my `/etc/default/grub` file:
#!bash
GRUB_CMDLINE_LINUX="tpm_tis.force=1 tpm_tis.interrupts=0 ..."
```console
GRUB_CMDLINE_LINUX="tpm_tis.force=1 tpm_tis.interrupts=0 ..."
```
The final `...` means that you should keep whatever was there before you
included those parameters, of course. Also, after you edit this file,
you need to regenerate the GRUB configuration file on `/boot`. Run the
following command as `root`:
#!bash
> grub2-mkconfig -o /boot/grub2/grub.cfg
```console
> grub2-mkconfig -o /boot/grub2/grub.cfg
```
Then, after I rebooted the system, I found that only adding those flags
was still not enough. I saw a bunch of errors on `dmesg`, which showed
@ -247,33 +251,36 @@ because the system is using the touchpad and the touchscreen to
determine whether it should resume from suspend or not. So basically
what you have to do is to disable those sources of events:
#!bash
echo TPAD > /proc/acpi/wakeup
echo TSCR > /proc/acpi/wakeup
```console
echo TPAD > /proc/acpi/wakeup
echo TSCR > /proc/acpi/wakeup
```
And voilà! Now everything should work as expected :-). You might want to
issue those commands every time you boot the system, in order to get
suspend to work every time, of course. To do that, you can create a
`/etc/rc.d/rc.local`, which gets executed when the system starts:
#!bash
> cat /etc/rc.d/rc.local
#!/bin/bash
```console
> cat /etc/rc.d/rc.local
#!/bin/bash
suspend_tricks()
{
echo TPAD > /proc/acpi/wakeup
echo TSCR > /proc/acpi/wakeup
}
suspend_tricks()
{
echo TPAD > /proc/acpi/wakeup
echo TSCR > /proc/acpi/wakeup
}
suspend_tricks
suspend_tricks
exit 0
exit 0
```
Don't forget to make this file executable:
#!bash
> chmod +x /etc/rc.d/rc.local
```console
> chmod +x /etc/rc.d/rc.local
```
Conclusion
----------

48
content/posts/gdb-and-systemtap-probes-part-1.md
View file

@ -30,24 +30,26 @@ systems, you can obtain this header file by installing the package
Here's a simple example of an application with a one-argument probe:
#!c
#include <sys/sdt.h>
```c
#include <sys/sdt.h>
int
main (int argc, char *argv[])
{
int a = 10;
int
main (int argc, char *argv[])
{
int a = 10;
STAP_PROBE1 (test_program, my_probe, a);
STAP_PROBE1 (test_program, my_probe, a);
return 0;
}
return 0;
}
```
As you can see, this is a very simple program with one probe, which
contains one argument. You can now compile the program:
#!bash
$ gcc test_program.c -o test_program
```console
$ gcc test_program.c -o test_program
```
Now you must be thinking: "*Wait, wait... Didn't you just forget to link
this program against some SystemTap-specific library or something?*" And
@ -59,15 +61,16 @@ As Tom said in [his blog post](http://tromey.com/blog/?p=687), this is
If you want to make sure your probe was inserted in the binary, you can
use `readelf` command:
#!bash
$ readelf -x .note.stapsdt ./test_program
```console
$ readelf -x .note.stapsdt ./test_program
Hex dump of section '.note.stapsdt':
0x00000000 08000000 3a000000 03000000 73746170 ....:.......stap
0x00000010 73647400 86044000 00000000 88054000 sdt...@.......@.
0x00000020 00000000 00000000 00000000 74657374 ............test
0x00000030 5f70726f 6772616d 006d795f 70726f62 _program.my_prob
0x00000040 65002d34 402d3428 25726270 29000000 e.-4@-4(%rbp)...
Hex dump of section '.note.stapsdt':
0x00000000 08000000 3a000000 03000000 73746170 ....:.......stap
0x00000010 73647400 86044000 00000000 88054000 sdt...@.......@.
0x00000020 00000000 00000000 00000000 74657374 ............test
0x00000030 5f70726f 6772616d 006d795f 70726f62 _program.my_prob
0x00000040 65002d34 402d3428 25726270 29000000 e.-4@-4(%rbp)...
```
*(I will think about writing an explanation on how the probes are laid
out on the binary, but for now you just have to care if you actually
@ -75,9 +78,10 @@ see an output from this* `readelf` *command.)*
You can also use SystemTap to perform this verification:
#!bash
$ stap -L 'process("./test_program").mark("*")'
process("./test_program").mark("my_probe") $arg1:long
```console
$ stap -L 'process("./test_program").mark("*")'
process("./test_program").mark("my_probe") $arg1:long
```
So far, so good. If you see an output like the one above, it means your
probe is correctly inserted. You could obviously use SystemTap to

74
content/posts/gdb-and-systemtap-probes-part-2.md
View file

@ -33,9 +33,10 @@ It is not the goal of this post to explain it in detail, but you might
want to give it a try by compiling your binary with debuginfo support
(use the `-g` flag on `GCC`), and do something like:
#!bash
$ stap -e 'probe process("/bin/foo").function("name") { log($$parms) }' -c /bin/foo
$ stap -e 'probe process("/bin/foo").statement("*@file.c:443") { log($$vars) }' -c /bin/foo
```console
$ stap -e 'probe process("/bin/foo").function("name") { log($$parms) }' -c /bin/foo
$ stap -e 'probe process("/bin/foo").statement("*@file.c:443") { log($$vars) }' -c /bin/foo
```
And that's it. You can read SystemTap's documentation, or
[this](http://sourceware.org/systemtap/wiki/AddingUserSpaceProbingToApps)
@ -48,18 +49,19 @@ Well, now let's get to the interesting part. It is time to make `GDB`
work with the `SDT` probe that we have put in our example code. Let's
remember it:
#!c
#include <sys/sdt.h>
```c
#include <sys/sdt.h>
int
main (int argc, char *argv[])
{
int a = 10;
int
main (int argc, char *argv[])
{
int a = 10;
STAP_PROBE1 (test_program, my_probe, a);
STAP_PROBE1 (test_program, my_probe, a);
return 0;
}
return 0;
}
```
It is a very simple example, and we will have to extend it later in
order to show more features. But for now, it will do.
@ -68,15 +70,16 @@ The first thing to do is to open `GDB` (with SystemTap support, of
course!), and check to see if it can actually see probe inserted in our
example.
#!bash
$ gdb ./test_program
GNU gdb (GDB) 7.5.50.20121014-cvs
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
...
(gdb) info probes
Provider Name Where Semaphore Object
test_program my_probe 0x00000000004004ae /home/sergio/work/src/git/build/gdb/test_program
```console
$ gdb ./test_program
GNU gdb (GDB) 7.5.50.20121014-cvs
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
...
(gdb) info probes
Provider Name Where Semaphore Object
test_program my_probe 0x00000000004004ae /home/sergio/work/src/git/build/gdb/test_program
```
Wow, it actually works! :-)
@ -91,9 +94,10 @@ use the `SDT` support.
Anyway, now it is time to start using this support. The first thing I
want to show you is how to put a breakpoint in a probe.
#!bash
(gdb) break -probe-stap my_probe
Breakpoint 1 at 0x4004ae
```console
(gdb) break -probe-stap my_probe
Breakpoint 1 at 0x4004ae
```
That's all! We have chosen to extend the `break` command in order to
support the new `-probe-stap` parameter. If you're wondering *... why
@ -112,12 +116,13 @@ the one reported by `break`: they should be the same.
Ok, so now, with our `breakpoint` in place, let's run the program and
see what happens.
#!bash
(gdb) run
Starting program: /home/sergio/work/src/git/build/gdb/test_program
```console
(gdb) run
Starting program: /home/sergio/work/src/git/build/gdb/test_program
Breakpoint 1, main (argc=1, argv=0x7fffffffdf68) at /tmp/example-stap.c:8
8 STAP_PROBE1 (test_program, my_probe, a);
Breakpoint 1, main (argc=1, argv=0x7fffffffdf68) at /tmp/example-stap.c:8
8 STAP_PROBE1 (test_program, my_probe, a);
```
As you can see, `GDB` stopped at the exact location of the probe.
Therefore, you are now able to put marks (i.e., probes) in your source
@ -135,11 +140,12 @@ inspect the probe's arguments? Yes, let's do it now!
Just remember that, in `SDT`'s parlance, the current probe's argument is
`a`. So let's print its value.
#!bash
(gdb) p $_probe_arg0
$1 = 10
(gdb) p a
$2 = 10
```console
(gdb) p $_probe_arg0
$1 = 10
(gdb) p a
$2 = 10
```
*"Hey, captain, it seems the boat really floats!"*

98
content/posts/gdb-and-systemtap-probes-part-3.md
View file

@ -59,19 +59,19 @@ Ok, so now we have to learn how to put `tracepoints` in our code, and
how to define actions for them. But before that, let's remember our
example program:
#!c
#include <sys/sdt.h>
```c
#include <sys/sdt.h>
int
main (int argc, char *argv[])
{
int a = 10;
int
main (int argc, char *argv[])
{
int a = 10;
STAP_PROBE1 (test_program, my_probe, a);
return 0;
}
STAP_PROBE1 (test_program, my_probe, a);
return 0;
}
```
Very simple, isn't it? Ok, to the `tracepoints` now, my friends.
@ -94,10 +94,11 @@ First of all, make sure you have `gdbserver` installed. If you use
Fedora, the package name you will have to install is `gdb-gdbserver`. If
you have it installed, you can do:
#!bash
$ gdbserver :3001 ./test_program
Process ./test_program created; pid = 17793
Listening on port 3001
```console
$ gdbserver :3001 ./test_program
Process ./test_program created; pid = 17793
Listening on port 3001
```
The second argument passed to `gdbserver` instructs it to listen on the
port 3001 of your loopback interface, a.k.a. `localhost`.
@ -109,14 +110,15 @@ for new connections to arrive. Don't worry, we will connect to it soon!
Now, go to another terminal and start `GDB` with our program:
#!bash
$ gdb ./test_program
...
(gdb) target remote :3001
Remote debugging using :3001
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
0x0000003d60401530 in _start () from /lib64/ld-linux-x86-64.so.2
```console
$ gdb ./test_program
...
(gdb) target remote :3001
Remote debugging using :3001
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
0x0000003d60401530 in _start () from /lib64/ld-linux-x86-64.so.2
```
The command you have to use inside `GDB` is `target remote`. It takes as
an argument the host and the port to which you want to connect. In our
@ -135,9 +137,10 @@ Ok, so now it is time to start our *trace experiment*!
In your `GDB` prompt, put a `tracepoint` in the probe named `my_probe`:
#!bash
(gdb) trace -probe-stap my_probe
Tracepoint 1 at 0x4005a9
```console
(gdb) trace -probe-stap my_probe
Tracepoint 1 at 0x4005a9
```
As you can see, the `trace` command takes exactly the same arguments as
the `break` command. Thus, you need to use the `-probe-stap` modified in
@ -152,13 +155,14 @@ For this example, we will use only the `collect` keyword, which tells
`GDB` to... hm... collect something :-). In our case, it will collect
the probe's first argument, or `$_probe_arg0`, as you may remember.
#!bash
(gdb) actions
Enter actions for tracepoint 1, one per line.
End with a line saying just "end".
>collect $_probe_arg0
>end
(gdb)
```console
(gdb) actions
Enter actions for tracepoint 1, one per line.
End with a line saying just "end".
>collect $_probe_arg0
>end
(gdb)
```
Simple as that. Finally, we have to define a `breakpoint` in the last
instruction of our program, because it is necessary to keep it running
@ -174,15 +178,16 @@ Ok, time to run our trace experiment. First, we must issue a `tstart` to
tell `GDB` to start monitoring the `tracepoints`. And then, we can
continue our program normally.
#!bash
(gdb) tstart
(gdb) continue
Continuing.
```console
(gdb) tstart
(gdb) continue
Continuing.
Breakpoint 1, main (argc=1, argv=0x7fffffffde88) at /tmp/test_program.c:10
10 return 0;
(gdb) tstop
(gdb)
Breakpoint 1, main (argc=1, argv=0x7fffffffde88) at /tmp/test_program.c:10
10 return 0;
(gdb) tstop
(gdb)
```
Remember, `GDB` is **not** going to stop your program, because
`tracepoints` are designed to not interfere with the execution of it.
@ -193,12 +198,13 @@ Now, we will be able to examine what the `tracepoint` has collected.
First, we will the `tfind` command to make sure the `tracepoint` has
hit, and then we can inspect what we ordered it to collect:
#!bash
(gdb) tfind start
Found trace frame 0, tracepoint 1
8 STAP_PROBE1 (test_program, my_probe, a);
(gdb) p $_probe_arg0
$1 = 10
```console
(gdb) tfind start
Found trace frame 0, tracepoint 1
8 STAP_PROBE1 (test_program, my_probe, a);
(gdb) p $_probe_arg0
$1 = 10
```
And it works! Notice that we are printing the probe argument using the
same notation as with `breakpoints`, even though we are not exactly

5
content/posts/gnupg-encrypt-to-self.md
View file

@ -47,8 +47,9 @@ to always encrypt the message to myself too.
You basically have to edit your `$HOME/.gnupg/gpg.conf` file and put
this setting there:
#!bash
hidden-encrypt-to ID
```console
hidden-encrypt-to ID
```
That's it. Now, whenever I send an encrypted message, GnuPG encrypts it
for me as well, so I just need to go to my “Sent/” folder, and decrypt

154
content/posts/improve-gcore-elf-headers.md
View file

@ -66,11 +66,13 @@ the binutils guys to fix it, which meant less work for us :-).
With a lot of help from Keith Seitz, I was able to bisect the problem
and found that it started with the following commit:
commit f6aec96dce1ddbd8961a3aa8a2925db2021719bb
Author: H.J. Lu <hjl.tools@gmail.com>
Date: Tue Feb 27 11:34:20 2018 -0800
```
commit f6aec96dce1ddbd8961a3aa8a2925db2021719bb
Author: H.J. Lu <hjl.tools@gmail.com>
Date: Tue Feb 27 11:34:20 2018 -0800
ld: Add --enable-separate-code
ld: Add --enable-separate-code
```
This is a commit that touches the linker, which is part of binutils.
So that means this is not GDB's problem, right?!? Hmm. No,
@ -95,75 +97,79 @@ everything (code and data) was put together in the same memory
region. What this means in practice is that, before, you would see
something like this when you examined `/proc/PID/smaps`:
00400000-00401000 r-xp 00000000 fc:01 798593 /file
Size: 4 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Rss: 4 kB
Pss: 4 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 4 kB
Referenced: 4 kB
Anonymous: 4 kB
LazyFree: 0 kB
AnonHugePages: 0 kB
ShmemPmdMapped: 0 kB
Shared_Hugetlb: 0 kB
Private_Hugetlb: 0 kB
Swap: 0 kB
SwapPss: 0 kB
Locked: 0 kB
THPeligible: 0
VmFlags: rd ex mr mw me dw sd
```
00400000-00401000 r-xp 00000000 fc:01 798593 /file
Size: 4 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Rss: 4 kB
Pss: 4 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 4 kB
Referenced: 4 kB
Anonymous: 4 kB
LazyFree: 0 kB
AnonHugePages: 0 kB
ShmemPmdMapped: 0 kB
Shared_Hugetlb: 0 kB
Private_Hugetlb: 0 kB
Swap: 0 kB
SwapPss: 0 kB
Locked: 0 kB
THPeligible: 0
VmFlags: rd ex mr mw me dw sd
```
And now, you will see two memory regions instead, like this:
00400000-00401000 r--p 00000000 fc:01 799548 /file
Size: 4 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Rss: 4 kB
Pss: 4 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 4 kB
Private_Dirty: 0 kB
Referenced: 4 kB
Anonymous: 0 kB
LazyFree: 0 kB
AnonHugePages: 0 kB
ShmemPmdMapped: 0 kB
Shared_Hugetlb: 0 kB
Private_Hugetlb: 0 kB
Swap: 0 kB
SwapPss: 0 kB
Locked: 0 kB
THPeligible: 0
VmFlags: rd mr mw me dw sd
00401000-00402000 r-xp 00001000 fc:01 799548 /file
Size: 4 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Rss: 4 kB
Pss: 4 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 4 kB
Referenced: 4 kB
Anonymous: 4 kB
LazyFree: 0 kB
AnonHugePages: 0 kB
ShmemPmdMapped: 0 kB
Shared_Hugetlb: 0 kB
Private_Hugetlb: 0 kB
Swap: 0 kB
SwapPss: 0 kB
Locked: 0 kB
THPeligible: 0
VmFlags: rd ex mr mw me dw sd
```
00400000-00401000 r--p 00000000 fc:01 799548 /file
Size: 4 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Rss: 4 kB
Pss: 4 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 4 kB
Private_Dirty: 0 kB
Referenced: 4 kB
Anonymous: 0 kB
LazyFree: 0 kB
AnonHugePages: 0 kB
ShmemPmdMapped: 0 kB
Shared_Hugetlb: 0 kB
Private_Hugetlb: 0 kB
Swap: 0 kB
SwapPss: 0 kB
Locked: 0 kB
THPeligible: 0
VmFlags: rd mr mw me dw sd
00401000-00402000 r-xp 00001000 fc:01 799548 /file
Size: 4 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Rss: 4 kB
Pss: 4 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 4 kB
Referenced: 4 kB
Anonymous: 4 kB
LazyFree: 0 kB
AnonHugePages: 0 kB
ShmemPmdMapped: 0 kB
Shared_Hugetlb: 0 kB
Private_Hugetlb: 0 kB
Swap: 0 kB
SwapPss: 0 kB
Locked: 0 kB
THPeligible: 0
VmFlags: rd ex mr mw me dw sd
```
A few minor things have changed, but the most important of them is the
fact that, before, the whole memory region **had** anonymous data in
@ -240,9 +246,8 @@ Linux also makes these checks, by the way.
The patch, finally
------------------
I
submitted
[the patch](https://sourceware.org/ml/gdb-patches/2019-04/msg00479.html) to
I submitted [the
patch](https://sourceware.org/ml/gdb-patches/2019-04/msg00479.html) to
the mailing list, and it was approved fairly quickly (with a few minor
nits).
@ -253,8 +258,7 @@ interesting to come up with a solution that extended the work I did a
few years ago. I was also able to close a few bug reports upstream,
as well as the one reported against Fedora GDB.
The patch has
been
The patch has been
[pushed](https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=57e5e645010430b3d73f8c6a757d09f48dc8f8d5),
and is also present at the latest version of Fedora GDB for Rawhide.
It wasn't possible to write a self-contained testcase for this

94
content/posts/installing-gerrit-and-keycloak.md
View file

@ -180,10 +180,12 @@ Java 8, but unlike Keycloak, it doesn't work out of the box with
OpenJDK 11. I had to make a small but important addition in the file
`etc/gerrit.config`:
[container]
...
javaOptions = "--add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED"
...
```ini
[container]
...
javaOptions = "--add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED"
...
```
After that, I was able to start gerrit. And then I started trying to
set it up for OAuth2 authentication using Keycloak. This took a
@ -198,52 +200,54 @@ causing a very strange error on Gerrit (as you can see, a
`java.lang.StringIndexOutOfBoundsException`!), which didn't make
sense. In the end, my Apache config file looks like this:
<VirtualHost *:80>
ServerName gnutoolchain-gerrit.osci.io
```apacheconf
<VirtualHost *:80>
ServerName gnutoolchain-gerrit.osci.io
RedirectPermanent / https://gnutoolchain-gerrit.osci.io/r/
</VirtualHost>
RedirectPermanent / https://gnutoolchain-gerrit.osci.io/r/
</VirtualHost>
<VirtualHost *:443>
ServerName gnutoolchain-gerrit.osci.io
<VirtualHost *:443>
ServerName gnutoolchain-gerrit.osci.io
RedirectPermanent / /r/
RedirectPermanent / /r/
SSLEngine On
SSLCertificateFile /path/to/cert.pem
SSLCertificateKeyFile /path/to/privkey.pem
SSLCertificateChainFile /path/to/chain.pem
SSLEngine On
SSLCertificateFile /path/to/cert.pem
SSLCertificateKeyFile /path/to/privkey.pem
SSLCertificateChainFile /path/to/chain.pem
# Good practices for SSL
# taken from: <https://mozilla.github.io/server-side-tls/ssl-config-generator/>
# Good practices for SSL
# taken from: <https://mozilla.github.io/server-side-tls/ssl-config-generator/>
# intermediate configuration, tweak to your needs
SSLProtocol all -SSLv3
SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
SSLHonorCipherOrder on
SSLCompression off
SSLSessionTickets off
# intermediate configuration, tweak to your needs
SSLProtocol all -SSLv3
SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
SSLHonorCipherOrder on
SSLCompression off
SSLSessionTickets off
# OCSP Stapling, only in httpd 2.3.3 and later
#SSLUseStapling on
#SSLStaplingResponderTimeout 5
#SSLStaplingReturnResponderErrors off
#SSLStaplingCache shmcb:/var/run/ocsp(128000)
# OCSP Stapling, only in httpd 2.3.3 and later
#SSLUseStapling on
#SSLStaplingResponderTimeout 5
#SSLStaplingReturnResponderErrors off
#SSLStaplingCache shmcb:/var/run/ocsp(128000)
# HSTS (mod_headers is required) (15768000 seconds = 6 months)
Header always set Strict-Transport-Security "max-age=15768000"
# HSTS (mod_headers is required) (15768000 seconds = 6 months)
Header always set Strict-Transport-Security "max-age=15768000"
ProxyRequests Off
ProxyVia Off
ProxyPreserveHost On
<Proxy *>
Require all granted
</Proxy>
ProxyRequests Off
ProxyVia Off
ProxyPreserveHost On
<Proxy *>
Require all granted
</Proxy>
AllowEncodedSlashes On
ProxyPass /r/ http://127.0.0.1:8081/ nocanon
#ProxyPassReverse /r/ http://127.0.0.1:8081/r/
</VirtualHost>
AllowEncodedSlashes On
ProxyPass /r/ http://127.0.0.1:8081/ nocanon
#ProxyPassReverse /r/ http://127.0.0.1:8081/r/
</VirtualHost>
```
I confess I was almost giving up Keycloak when I finally found
the problem...
@ -259,10 +263,12 @@ gerrit that the user was already logged in, and gerrit would
automatically log the user in again! I was able to solve this by
redirecting the user to Keycloak's logout page, like this:
[auth]
...
logoutUrl = https://keycloak-url:port/auth/realms/REALM/protocol/openid-connect/logout?redirect_uri=https://gerrit-url/
...
```ini
[auth]
...
logoutUrl = https://keycloak-url:port/auth/realms/REALM/protocol/openid-connect/logout?redirect_uri=https://gerrit-url/
...
```
After that, it was already possible to start worrying about configure
gerrit itself. I don't know if I'll write a post about that, but let

24
content/posts/migration-jabberd2-to-prosody.md
View file

@ -156,10 +156,11 @@ here](http://sergiodj.net/~sergio/jabberd2-migration/j2to1.txt). Save
the file as `j2to1.pl`, and run the script (don't forget to edit the
source code in order to provide the database name/file):
#!bash
$> perl j2to1.pl jabberd14-dir/
Converting user@host...
$>
```console
$> perl j2to1.pl jabberd14-dir/
Converting user@host...
$>
```
This will convert the database from Jabberd2 to Jabberd14, and put the
XML file of each Jabber user in the server into `jabberd14-dir/host/`.
@ -171,8 +172,9 @@ page](https://github.com/Kev/sleekmigrate) on how to set it up, you can
run it on your Jabberd14 data directory in order to finally generate a
XEP-0227 XML file that will be imported into Prosody.
#!bash
$> ./sleekmigrate.py -j /path/to/jabberd14-dir/
```console
$> ./sleekmigrate.py -j /path/to/jabberd14-dir/
```
This should create a file called `227.xml` on your current directory,
which is the exported version of the Jabberd14 data directory. As a side
@ -194,15 +196,17 @@ working. I also had to build some POSIX module of Prosody in order to
make everything work. To do that, unpack the `tar.gz` file, go to the
Prosody source code directory, and do:
#!bash
$> apt-get build-dep prosody && ./configure --ostype=debian && make
```console
$> apt-get build-dep prosody && ./configure --ostype=debian && make
```
Only after I did that I could finally run the conversion script
successfully. The script is locate inside the `tools/` directory. To run
it:
#!bash
$> cd tools && lua ./xep227toprosody.lua /path/to/227.xml
```console
$> cd tools && lua ./xep227toprosody.lua /path/to/227.xml
```
And yay! I **finally** had everything imported into Prosody!!!! Then it
was just a matter of finishing the server configuration, initializing

4
content/posts/using-wireguard-host-services-home.md
View file

@ -42,7 +42,7 @@ little configuration.
On the server side (i.e., VPS or dedicated server), you will create
the first endpoint. Something like the following should do:
```nil
```ini
[Interface]
PrivateKey = PRIVATE_KEY_HERE
Address = 10.0.0.1/32
@ -73,7 +73,7 @@ A few interesting points to note:
At your home, you will configure the peer:
```nil
```ini
[Interface]
PrivateKey = PRIVATE_KEY_HERE
Address = 10.0.0.2/32