diff --git a/content/posts/debuginfod-for-debian.md b/content/posts/debuginfod-for-debian.md index 3e157aa..7e0c5e8 100644 --- a/content/posts/debuginfod-for-debian.md +++ b/content/posts/debuginfod-for-debian.md @@ -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" ``` diff --git a/content/posts/fedora-on-acer-c720p.md b/content/posts/fedora-on-acer-c720p.md index b00f6e0..5bc9987 100644 --- a/content/posts/fedora-on-acer-c720p.md +++ b/content/posts/fedora-on-acer-c720p.md @@ -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 ---------- diff --git a/content/posts/gdb-and-systemtap-probes-part-1.md b/content/posts/gdb-and-systemtap-probes-part-1.md index 7096eb5..0006b2d 100644 --- a/content/posts/gdb-and-systemtap-probes-part-1.md +++ b/content/posts/gdb-and-systemtap-probes-part-1.md @@ -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 +```c +#include - 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 diff --git a/content/posts/gdb-and-systemtap-probes-part-2.md b/content/posts/gdb-and-systemtap-probes-part-2.md index 2e6659c..e041518 100644 --- a/content/posts/gdb-and-systemtap-probes-part-2.md +++ b/content/posts/gdb-and-systemtap-probes-part-2.md @@ -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 +```c +#include - 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 - ... - (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 +... +(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!"* diff --git a/content/posts/gdb-and-systemtap-probes-part-3.md b/content/posts/gdb-and-systemtap-probes-part-3.md index 8582802..a7d686c 100644 --- a/content/posts/gdb-and-systemtap-probes-part-3.md +++ b/content/posts/gdb-and-systemtap-probes-part-3.md @@ -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 +```c +#include - 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 diff --git a/content/posts/gnupg-encrypt-to-self.md b/content/posts/gnupg-encrypt-to-self.md index c8c07d3..ab103ae 100644 --- a/content/posts/gnupg-encrypt-to-self.md +++ b/content/posts/gnupg-encrypt-to-self.md @@ -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 diff --git a/content/posts/improve-gcore-elf-headers.md b/content/posts/improve-gcore-elf-headers.md index c0e10fc..70727a4 100644 --- a/content/posts/improve-gcore-elf-headers.md +++ b/content/posts/improve-gcore-elf-headers.md @@ -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 - Date: Tue Feb 27 11:34:20 2018 -0800 +``` +commit f6aec96dce1ddbd8961a3aa8a2925db2021719bb +Author: H.J. Lu +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 diff --git a/content/posts/installing-gerrit-and-keycloak.md b/content/posts/installing-gerrit-and-keycloak.md index a25c8b8..f5147c0 100644 --- a/content/posts/installing-gerrit-and-keycloak.md +++ b/content/posts/installing-gerrit-and-keycloak.md @@ -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: - - ServerName gnutoolchain-gerrit.osci.io +```apacheconf + + ServerName gnutoolchain-gerrit.osci.io - RedirectPermanent / https://gnutoolchain-gerrit.osci.io/r/ - + RedirectPermanent / https://gnutoolchain-gerrit.osci.io/r/ + - - ServerName gnutoolchain-gerrit.osci.io + + 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: + # Good practices for SSL + # taken from: - # 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 - - Require all granted - + ProxyRequests Off + ProxyVia Off + ProxyPreserveHost On + + Require all granted + - AllowEncodedSlashes On - ProxyPass /r/ http://127.0.0.1:8081/ nocanon - #ProxyPassReverse /r/ http://127.0.0.1:8081/r/ - + AllowEncodedSlashes On + ProxyPass /r/ http://127.0.0.1:8081/ nocanon + #ProxyPassReverse /r/ http://127.0.0.1:8081/r/ + +``` 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 diff --git a/content/posts/migration-jabberd2-to-prosody.md b/content/posts/migration-jabberd2-to-prosody.md index a0fb850..bbdb6e3 100644 --- a/content/posts/migration-jabberd2-to-prosody.md +++ b/content/posts/migration-jabberd2-to-prosody.md @@ -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 diff --git a/content/posts/using-wireguard-host-services-home.md b/content/posts/using-wireguard-host-services-home.md index 1539390..26d70b4 100644 --- a/content/posts/using-wireguard-host-services-home.md +++ b/content/posts/using-wireguard-host-services-home.md @@ -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