commit 8bdcfe8df27752fe586725262d5f8cbfa15fcb87 parent 99862637985e08c7de963ecca268e8685dc29181 Author: Paco Esteban <paco@onna.be> Date: Tue, 30 Jul 2019 15:49:54 +0200 big reorganisation * we use ssg now for html rendering * we use rssg for rss generation * we use now ggen to generate the gopherhole Diffstat:
78 files changed, 2026 insertions(+), 2320 deletions(-)
diff --git a/Makefile b/Makefile @@ -0,0 +1,29 @@ +TITLE="onna.be" +BASE_URL="https://onna.be" +SRC_DIR=src +DST_DIR=htmlOut +HTTP_SERVER="r2.e1e0.net:/var/www/htdocs/onna.be" +GOPHER_DIR=gopherOut +GOPHER_SERVER="r2.e1e0.net:/var/gopher" +MARKDOWN_FILES != find ./$(SRC_DIR) -name '*.md' + +.PHONY: all html rss gopher sync + +all: html rss gopher sync + +html: + @mkdir -p $(DST_DIR) + @ssg5 $(SRC_DIR) $(DST_DIR) $(TITLE) $(BASE_URL) + +rss: $(DST_DIR)/rss.xml + +$(DST_DIR)/rss.xml : $(DST_DIR)/index.html + @rssg $(SRC_DIR)/index.html $(TITLE) $(BASE_URL) > $(DST_DIR)/rss.xml + +gopher: + @mkdir -p $(GOPHER_DIR) + @ggen $(SRC_DIR) $(GOPHER_DIR) + +sync: + @rsync -avz --delete $(DST_DIR)/ $(HTTP_SERVER)/ + @rsync -avz --delete $(GOPHER_DIR)/ $(GOPHER_SERVER)/ diff --git a/content/blocking-abusers.md b/content/blocking-abusers.md @@ -1,90 +0,0 @@ -title: Blocking abusers on personal servers (OpenBSD PF) -author: paco -date: 2018-09-07 -css: style.css - -XXmenuXX - ---------- -# Blocking abusers on personal servers (OpenBSD PF) -2018-09-07 - -Inspired by Jordan Geoghegan's article about [pf-badhost][1] I wanted to -create my own list based on the "attack attempts" I get on my personal -servers. This was tested on OpenBSD 6.3. - -I just put together a small shell script that parses the httpd(8) logs -and creates 2 files. One to load into a PF table and another one with -entries I'm not sure about and had to be checked manually (either to add -them to the patterns to search for or to discard them as legit). - -It's all really simple. The script is this one: - - - #!/bin/sh - - FILE=$1 - BLOCK=$2 - BAD="" - UNKNOWN="" - - patterns="login.cgi - admin - php - webdav - iframe" - - [ -z "$FILE" ] && echo "Need a log file" && exit 1 - - while IFS= read -r line - do - # ignore first line (rotation) - echo "$line" | grep -q newsyslog && continue - - #gather some info - IP=$(echo "$line" | awk '{print $2}') - REQ=$(echo "$line" | awk -F'"' '{print $2}' | awk '{print $2}') - - # if you're behind a NAT and want to remove your network segment ... - # is not really needed if you just filter on egress, but still. - # echo "$IP" | grep -q "^10\\.42" && continue - - # sort things into unknown and bad folks - if echo "$REQ" | grep -q -e "$patterns" ; then - BAD="${BAD}${IP} - " - else - UNKNOWN="${UNKNOWN}${IP} ($REQ) - " - fi - done < "$FILE" - - echo "$BAD" | sort -uV > /tmp/bad_folks.txt - echo "$UNKNOWN" | sort -uV >> /tmp/to_check.txt - - # and now we clean for duplicates and stuff ... - cat /etc/pf_tables/bad_folks.txt >> /tmp/bad_folks.txt - sort -uV /tmp/bad_folks.txt > /etc/pf_tables/bad_folks.txt - - # and clean - rm /tmp/bad_folks.txt - - if [ "$BLOCK" = "block" ]; then - doas pfctl -t bad_folks -T replace -f /etc/pf_tables/bad_folks.txt - fi - -Just fill the `patterns` variable with one grep pattern per line. - -Of course you'll have to add some rules to `pf.conf`: - - - table <bad_folks> persist file "/etc/pf_tables/bad_folks.txt" - block in quick on egress from <bad_folks> to any - -Remember to add the necessary permissions on `doas.conf` to the user that runs -the script. - ----- -[1]: https://www.geoghegan.ca/pfbadhost.html - -Last updated: XXlastXX diff --git a/content/browser-dependency.md b/content/browser-dependency.md @@ -1,287 +0,0 @@ -title: Trying to avoid browser dependency. -author: paco -date: 2019-05-07 -css: style.css - -XXmenuXX - ---------- -# Trying to avoid browser dependency. -2019-05-07 - -Web browsers are almost the only GUI programs I use. They are also the most -bloated and vulnerable programs one can have installed on desktop/laptop. - -Those browsers have to handle a lot of external code that comes from the -websites visited. Not only static html (which is already problematic in some -cases) but also JavaScript, which has to be interpreted and run in your machine -with the obvious risk. - -Is not only a matter of security, but also privacy. Almost every website out -there is tracking you in some way or another. Or worst, is using one of the big -companies to track you, which makes their profiling even easier ... - -And then there's the _ups!_ moments like the recent [Firefox bug][1] that -deactivated all the user plugins. The worst part in my opinion is trying to fix -the thing using the _"Studies system"_, which already has a reputation ... - -The other big browser, Chrome is not free of all this stuff. They spy on you -directly without even hiding it. - -Here you can find a series of techniques to use web browsers as little as -possible. - -## Basic browsing - -For basic stuff, like sites that are mostly text as Wikipedia or others, one -can use a text based browser like [lynx][2]. This becomes impossible with sites -that make heavy use of JavaScript or sites that require captcha to login ... In -that case, the only alternative I can think of is use a conventional browser -with plugins like uBlock Origin or Privacy Badger. - -## Bookmarks - -There are some ways of have your bookmarks totally independent from a browser. -I choose to use [shiori][3]. It's a terminal utility that you can use to add, -search, or open bookmarks. It also has a web interface if you prefer that. - -A simple search can be done like this: - - shiori search keyword - -You cal also specify tags in the search with `-t`. Then you can open it in your -default browser with: - - shiori open id - -Take a look at `help`, it's really easy. - -You can also import/export bookmarks in html format as most browsers -understand, so migrating to/from `shiori` is quite easy. - -## Downloads - -Whenever I can, I use [curl][4], `ftp(1)` or [wget][5] from the command line with -direct links. If using a text based browser, then it should have its own way of -dealing with downloads. - -Some sites do not like user that do not use conventional browsers, as those are -more difficult to track (not impossible, just a bit more difficult). Some of -them block requests that don't come from _"regular"_ user agents, so it's -usually a good idea to configure your tools to identify themselves as Mozilla -Firefox or Google Chrome. Most of the times that is enough. - -If using bittorrent to download stuff, the problem is to find a torrent website -that is not completely full of crap and you can just take the magnet links -(because you should be using magnet links). Try to use API calls if your -favourite tracker allows it. - -I usually use [rarbg][6]. You have a lot of alternatives to interact with its -[api][7]. A long time ago I did some Perl module for it called -[Rarbg::torrentapi][8]. Then I use a sort of interactive script to search -torrents on the terminal, it pairs with [transmission][9] to send the magnet -links directly to the torrent client. - - #!/usr/bin/env perl - - use v5.24; - use strict; - use warnings; - use Rarbg::torrentapi; - use Getopt::Long; - no warnings 'experimental'; - - sub usage { - say - "Usage: $0 [--list] [--search <string>] [--categories <category>] [--limit <n>]"; - say "\t--list\t\t\tlists last added torrents sorted by seeds."; - say - "\t--search <string>\tsearches for <string> and returns sorted by seeds"; - say - "\t--category [movies|tv|music|xxxx]\tuses those categories (defaults to movies)"; - say "\t--limit [25|50|100]\tShows 'n' results (defaults to 25)"; - exit 1; - } - - my $tapi = Rarbg::torrentapi->new(); - my $counter = 0; - my $search = ""; - my $list; - my $result; - my $raw_category = ''; - my $category; - my $limit = 25; - - GetOptions( - "search=s" => \$search, - "list" => \$list, - "category=s" => \$raw_category, - "limit=i" => \$limit - ) or usage(); - - given ($raw_category) { - when ( $_ eq 'movies' or $_ eq 'tv' ) { - $category = $raw_category; - } - when ( $_ eq 'music' ) { - $category = '2;23;24;25;26'; - } - default { - $category = 'movies' - } - } - - if ($search) { - $result = $tapi->search( - { sort => 'seeders', - limit => $limit, - category => $category, - search_string => $search - } - ); - } - elsif ($list) { - $result = $tapi->list( - { sort => 'seeders', - limit => $limit, - category => $category - } - ); - } - else { - usage(); - } - - if ( ref($result) eq 'ARRAY' ) { - foreach my $t ( @{$result} ) { - printf( - "%d -> %s (%.2f GB # %d seeds)\n", - $counter, $t->title, $t->size / 1073741824, - $t->seeders - ); - $counter++; - } - } - elsif ( ref($result) eq 'Rarbg::torrentapi::Error' ) { - die "[*] We got an error: $result->{error}"; - } - else { - die "[*] Unexpected Error"; - } - - print "Input selection, separated by spaces. (Ctrl+C to quit) "; - my $selection = <STDIN>; - chomp $selection; - - if ( $selection =~ m/\d{1,2} ?/ ) { - my @selections = split( / /, $selection ); - foreach my $s (@selections) { - say "[*] You selected: " . $result->[$s]->title; - say " [-] sending magnet to transmission:\n" - . $result->[$s]->download; - my $magnet = $result->[$s]->download; - `transmission-remote MYTORRENTHOST --authenv -a $magnet`; - } - } - else { - die "selection is not a number!"; - } - -## RSS feeds - -The best solution I found for this is [newsboat][10]. You can use it directly -(providing a list of feeds to pull from) or connecting it to a supported -external service like [ttrss][11]. I happen to have access to a `ttrss` -installation, so I use that and also have the Android app on my phone. That way -I keep track of what I have read/seen. - -`newsboat` allows you to configure the browser it will use to open links. I -find useful to have a wrapper script as configured browser, so it routes the -different kinds of links to different programs, and defaults to a web browser -if needed. I also use it for other stuff on the command line, is pretty -convenient. - - #!/usr/bin/env bash - - ext="${1##*.}" - videoSites="youtube.com|youtu.be|diode.zone|peertube.social" - videoFiles="mkv mp4 gif webm mpd" - audioFiles="mp3 flac" - imageFiles="png jpg jpeg" - - if echo "$imageFiles" | grep -q -w "$ext"; then - feh -q "$1" & disown - elif echo "$videoFiles" | grep -q -w "$ext"; then - mpv --really-quiet --pause --keep-open "$1" & disown - elif echo "$audioFiles" | grep -q -w "$ext"; then - # I like podcasts and the like to open on a small terminal - urxvtc -geometry 60x6 -e mpv --pause --keep-open "$1" & disown - elif echo "$@" | grep -q -E "$videoSites"; then - mpv --really-quiet --pause "$1" & disown - else - firefox --private-window "$1" > /dev/null 2>&1 & disown - fi - -And then you tell `newsboat` to use it like so: - - browser "/path/to/my/script/linkhandler.sh %u" - -## Images - -You can use [feh][12] to see links to images. It just works. - -It can also be used to set up your background image on simple window managers, -invoked from `.xinitrc` or `.xsession` - -## Videos (and streaming) - -A good alternative to watch videos and streaming on the browser is [mpv][13]. It -has integration with [youtube-dl][14] (which not only "understands" youtube -links, but many many more). With a bit of configuration you won't need the -browser for video any more. Here is my `~/.config/mpv/mpv.conf` - - # sound works better like this on OpenBSD - ao=sndio - # try gpu accelerated video - vo=gpu,xv - # full screen by default - fs=yes - # user agent ... because the web sucks. - user-agent="Mozilla/5.0 (Windows NT 6.1; rv:60.0) Gecko/20100101 Firefox/60.0" - # moarrr cache - cache=yes - cache-default=8192 - # no 4k monitor so limit to best 1080 - ytdl-format=bestvideo[height <= 1080]+bestaudio/best - # do not send that through the HE tunnel (ignore if you do not have this) - ytdl-raw-options=force-ipv4= - -Keep in mind that some streams might not work with mpv under OpenBSD (my OS of -choice). That's because `ffmpeg` does not come with DASH demuxing compiled in -by default. I sent a patch to the port maintainer some time ago. I hope it will -be commited soon. In the mean time contact me if you need that functionality -and I'll send you the patch and instructions. - -## Conclusion - -So those are the programs I use to try to stay away from the browser as much as -possible. If you have other alternatives or suggestions, contact me and I'll -add them here. - ---- -[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1548973 -[2]: https://lynx.invisible-island.net/ -[3]: https://github.com/RadhiFadlillah/shiori -[4]: https://curl.haxx.se/ -[5]: https://www.gnu.org/software/wget/ -[6]: https://rarbg.com/ -[7]: https://torrentapi.org/ -[8]: https://metacpan.org/pod/Rarbg::torrentapi -[9]: https://transmissionbt.com/ -[10]: https://newsboat.org/ -[11]: https://tt-rss.org/ -[12]: https://feh.finalrewind.org/ -[13]: https://mpv.io/ -[14]: https://youtube-dl.org/ - -Last update: XXlastXX diff --git a/content/brymen869s-serial-cable.md b/content/brymen869s-serial-cable.md @@ -1,70 +0,0 @@ -title: Brymen 869s Serial cable build. -author: paco -date: 2018-12-08 -css: style.css - -XXmenuXX - ---------- -# Brymen 869s Serial cable build. -2018-12-08 - -The Brymen 869s is a fantastic multimeter. Among a lot of other -functionalities it has serial communication to a PC. The problem is -the cable for this is hugely overpriced. Luckily building one is not so -complicated. Besides, some clever folks on the [EEVBlog Forum][1] have -already decoded the protocol the cable uses. - -Well, the usb protocol the cable uses is public, but the protocol used -between the meter and the serial adapter is not. - -This is a infrared communication (so it keeps isolated the pc and the -meter), so some infrared LED and photodiode (or a phototransistor) are -needed. The parts list for all the circuit are small. - - * One micro controller (ATTiny85 in my case, use what you're - comfortable with). - * One infrared diode. - * One current limiting resistor for it. - * (In my case) one NPN BJT, as the micro could not output enough - current for the LED I used. But this is optional if your LED is - directly driven by the micro. - * One photodiode or phototransistor. - * One suitable limiting resistor for that one too. - * A usb to serial adapter if your micro cannot talk usb directly. - -I've attached the [schematic][2] of what I did come up with with the parts -I had lying around at home. - -The [code][3] is just adapted from what user 'jesuscf' did on the EEVBlog -Forum for arduino. I "ported" it to work with AVR C on the ATTiny85. - -The interesting part is how it works. The 'cable' (ATTiny85 driving the -IR LED in this case), sends a 10ms pulse to the meter, it then waits for -the signal from the meter to go high. After that the cable starts -sending a clock signal and the meter starts sending data synced with -that clock. - -One complete "packet" are 20 bytes. Sixteen of them are data and the -last four are fix. The description of each byte can be seen on bm869s.h - -Once we got data, is just a matter of deciding what and how to send it -to the pc via serial. - -I've also designed a small 3D printed case for it, similar to the -original cable attachment, so the circuit can be easily attached to the -meter and the LEDs are well placed, pointing in the right direction and -with almost no interference from other sources. The design is on the -repo. It's a FreeCAD file. I've also uploaded an [STL file][4] in case -somebody wants to use it without installing FreeCAD. - -All and all a small but pretty fun project to do on a weekend. And now I -have data logging on my meter for almost no cost. - ------ -[1]: https://www.eevblog.com/forum/testgear/brymen-ir-connection-protocol-anyone-sniffed-it-yet/ -[2]: https://onna.be/files/brymen_cable_schematic.png -[3]: https://git.onna.be/brymen_bm869s_ir_cable/ -[4]: https://onna.be/files/brymen_cable_attachemnt_v2.stl - -Last updated: XXlastXX diff --git a/content/free-cetus.md b/content/free-cetus.md @@ -1,218 +0,0 @@ -title: Cetus3D printer mods (free cetus !) -author: paco -date: 2019-01-16 -css: style.css - -XXmenuXX - ---------- -# Cetus3D printer mods (free cetus !) -2019-01-16 - -The Cetus is a 3D printer by [Tiertime][1]. -It's small and affordable (although not on the super cheap range of the -Chinese printers). Also the quality of the build and hardware components -is quite good, featuring linear rails and a 32bit cpu. - -The downside to this printer is that the firmware on the printer is not -open source, and it does not work with gcode as the vast majority of the -other printers on the market do. Once you buy it, you're stuck with the -slicer that Tiertime provides which, of course, only works for Mac and -Windows ... and although it is super simple and "it just works", it's -really annoying in some aspects. - -So, there's the reason on trying to fix something that's not broken. - -There's a [company][2] that has developed a drop-in replacement of the -original cpu board, but that runs with an open source firmware -([smoothieware][3]). - -The main goal is to use open source software on all the steps of the -process, from design to print, so I won't have nasty surprises in the -future (when Tiertime discontinues the printer, or stops giving support -for it, or any of the fun stuff companies like to do, so they try to -force you to buy new products) and use the OS that I want, and also a -better control of the print settings for some 3D models that need more -than the basics. - -The model I own is a MKII. This model does not have end stop switches. -The homing is done when the cpu detects that the motors are stuck -because they have reached end of travel. A bit crude, but I guess it -saves cost on production. - -So, the first step for this conversion is to install limit switches. -This is called "downgrade to MKI by Tinyfab". This needs to be done -because the new cpu does not support that kind of brute homing. Also, I -prefer the switch homing, as is less aggressive with the hardware, -specially the motors and some small printed parts - -[Here][4] and [here][5] you can find a tarball with the files needed to print -the adapters for the limit switches. They are the same files provided by -Tinyfab, but renamed so it's clear which ones do you need to use. - -You'll need both X and Y axis pieces and one of the Z axis pieces -depending on the model you have (standard or extended). - -If you plan to use a capacitive bed sensor, print also the piece to fix it to -the hot end carriage. [Here][6] and [here][7] you can find a 3D model I did for -that, as the one Tinyfab provides was broken for me. - -Print this before any disassemble of the machine of course ! - -You can check the installation process on Tinyfab website. For me it was -a little bit different than the pictures they show. So I'll try to -describe it. - -* Remove the X motor (the one for the bed). That will set the belt - loose. Insert the small X axis piece on the aluminium profile, put - together the other part and the limit switch and secure that with - screws to the piece you just inserted on the profile. Put then back - the motor in place. You can push the tension mechanism for the belt - from the other side of the track to make your life easier when putting - back the belt on the pulley. - -* This one is the tricky one. The Y axis. Remove the motor too. In my - case I had to remove the motor mount too, as you have to reach the - screw that secures the belt to the hot end carriage. Be careful, as - this will set the tension belt mechanism loose and the spring is quite - strong. Pull out (but not entirely) the carriage, so the mentioned - screw is visible. Take it out and replace it for the longer piece you - printed. This is the one that will activate the limit switch. Put all - back together carefully. Now remove the small cable routing piece that - is attached to the motor, and replace it with the bigger Y axis piece - you printed. The limit switch goes inside it. - -* The last one, Z, is the easy one. Just take out the first 2 screws on - the vertical linear rail and pull out the whole cap (oh, you should - remove the filament if you have any and the plastic tube). The limit - switch goes inside the new cap. It can be a bit difficult to see, but - there are a couple of holes for screws inside the piece so you can - secure the switch to it. The switch bearing faces up. The pictures on - the website may give you a hint. - -Now it's time to open the main printer case and access the motherboard. - -Remove the current _"limit switches"_, in case of the MKII those are some -extensions to the cables that come from the motors. Connect the new ones -in place and route the cables so they are not in the way and all axis -can move freely. I routed mine below the Z axis motor. - -In case you also want to use the bed capacitive probe, you'll have to -solder a connector to the "case open" slot and put the X axis limit -switch there (and the bed probe where the X limit is supposed to be). -This is needed because the case open slot does not provide the power -needed by the capacitive sensor. Also, some changes will be needed on -the config later. - -Remove the stock cpu and replace it by the tinyfab one. Simplest step in -the whole process. - -Get the last firmware file from Tinyfab website. It comes with an -example config file already. - -Connect the printer via USB to a computer. It will appear as an external -drive. That's the SD card on the printer board. - -At this point, if you just copy the config file as the Tinyfab docs say -and reboot the printer, you're almost good to go. Put there the firmware -and rename it to 'firmware.bin' so it gets upgraded on next boot, just -in case the cpu did not have the last version installed already. - -Set up the `gamma_max`, which is the max travel on the Z axis. I did -this manually with the _"paper"_ method. So connect with a Gcode sender -program like Repetier-Host or UGS. Then: - -* Home all axis with `G28` (be prepared to turn the printer off in case of - failure, one axis going to the other side, ....) -* Set coordinates to absolute with G90 -* Go to 0,0 on XY with `G0 X0 Y0` -* Lower Z until the nozle traps the paper. Take a look at Z position. - That's your new `gamma_max`. - -Now, enjoy your free 3D printing experience ! - -I did some config tweaks though. [Here][8] and [here][9] they are for -reference. - -Basically, I removed the section for the second hotend, as it was -bothering me and I'll never have one on this printer. - -Changed the X axis limit switch pin, as there is now the capacitive bed -sensor, so `alpha_max_endstop` is now `2.13^` - -I also enabled the zprobe, set up the good pin number `1.24!^` and did the -bed level process. It's a bit tricky, but it works in the end (mind that -I use the "Rectangular grid compensation" method as described on -smoothieware [website][10], maybe the easier triangular method is enough) - -* Home all axis with `G28` -* Start the probe process with `G32` -* Save the results and the calibration file with `M500` and `M374` -* Home again and you're good to go. - -This calibration will be read on power up by the printer, so no need to -do it again unless you change something related to the bed plate. - -Some things to take into consideration, I cheated a bit to be able to -perform the process. The way it works is, you define a bed size and an -odd number to be the size of the probing grid, in my case 7 (so 7x7 -points will be probed). You al so need to enter the offset of the nozle -and the probe. The problem is that that offset gets added to the bed -dimensions for probing, so in my case the offset would be +40 for the X -and -10 for the Y, that means that the probing would start at -40 on the -X and will end on 190 on the Y. Maybe for other printers that makes -sense, but the Cetus has its travel limited to the size of the bed. - -So what I end up doing, was set up a bed grid size of 140 on the X by -170 on the Y and setting up only the Y offset. It's not perfect, but is -close enough and it works kind of right. - -Also I did a pid temperature auto test. You can get more info about -this [here][11]. It can easily be done with the command: - - M303 E0 S210 - -`M303` is the actual command, `E0` is the heater (0 as is the first and -only), and `Sxxx` is the target temperature. Use a temperature you're -going to use in real prints. - -At the end you'll get a message like: - - Cycle 4: max: 246.189, min: 227.627, avg separation: 0.418274 - Ku: 34.9838, Pu: 39.85 - Trying: - Kp: 21.0 - Ki: 1.053 - Kd: 105 - PID Autotune Complete! The settings above have been loaded into memory, but not written to your config file. - -So there you have your pid values you can put on the config file. Mine -won't be probably good for you, although default ones may work. - -And finally I modified the max PWM value for the hot end control. The -default was 160 and I could not get the hot end to temperature ... it -fell always short. Maybe 255 is too much and a little lower is ok, I -still have to try that. I hope is not too much and I don't fry -something. - -With all this, the Cetus is now a normal printer you can use in -combination with the open source slicer and gcode sender of your choice. -I personally prefer [Slic3r][12] and [Octoprint][13] (so the printer is not -right next to me). - ------ -[1]: https://www.cetus3d.com/ -[2]: https://www.tinyfab.xyz/ -[3]: http://smoothieware.org/ -[4]: https://onna.be/files/cetus_limit_switch.tar.gz -[5]: gopher://onna.be:70/0/files/cetus_limit_switch.tar.gz -[6]: https://onna.be/files/cetus_zprobe_holder.stl -[7]: gopher://onna.be:70/0/files/cetus_zprobe_holder.stl -[8]: https://onna.be/files/cetus_config.diff -[9]: gopher://onna.be:70/0/files/cetus_config.diff -[10]: http://smoothieware.org/zprobe#probing-for-cartesian-machines -[11]: http://smoothieware.org/temperaturecontrol#pid-autotuning -[12]: https://slic3r.org/ -[13]: https://octoprint.org/ - -Last updated: XXlastXX diff --git a/content/gopher.md b/content/gopher.md @@ -1,106 +0,0 @@ -title: Gopher ! -author: paco -date: 2018-08-04 -css: style.css - -XXmenuXX - ---------- -# Gopher ! -2018-08-04 - -It came to my attention that [gopher][1] is still active. And I could not -anticipate how active ! - -I like it's simplicity, and the lack of ads/tracking/otherevils so I -though that I would put the content of this site (for what is worth) -available on port 70 too. - -Here's how, so I don't forget immediately. - -This is tested on OpenBSD 6.3 and 6.4. - -First, install a gopher server. In this case [gophernicus][2] - - $ doas pkg_add gophernicus - -I used inetd(8) to expose gophernicus to the world, adding this line to -/etc/inetd.conf: - - gopher stream tcp nowait _gophernicus /usr/local/libexec/in.gophernicus in.gophernicus -h "onna.be" -nv - -`-h` is hostname, and should be a valid one (the hostname of the -machine). `-nv` is disable virtual hosting, which I don't use. There's -more options in it's help or github, but with `-h` you're good to go. - -By default gophernicus will server content on `/var/gopher`. So once -inetd is (re)started, you can take your gopher client of choice and take -a look. You should see something like - - Welcome to Gophernicus! - _______ __ __ - | __|.-----.-----.| |--.-----.----.-----.|__|.----.--.--.-----. - | | || _ | _ || | -__| _| || || __| | |__ --| - |_______||_____| __||__|__|_____|__| |__|__||__||____|_____|_____| - |__| - - If you can see this, it means that the installation of Gophernicus - on this system was successful. You may now add content to this - directory and replace this page. - - ... - - -That's the default "gophermap". You can start adding content to the -default folder at this time, but modifying the gophermap to look better -and link to some content is better. - -For some instructions on how this gopher protocol works, take a look at -this [readme][3] from gophernicus. - -Mine is the same content served on http. I decided not so long ago to -just write everything in plain text and create index.html/gophermaps as -needed. So simplicity to the max. - - o--o-- Articles - - 0Barcodes, Partkeepr and parts providers(TME) partkeepr_barcodes_and_TME.txt onna.be 70 - 0Password management in the terminal done right. pass_terminal.txt onna.be 70 - -As the readme pointed earlier explains, first line is just text (you can -write or put fancy ASCII banners or whatever). Then the links have this -syntax: - - Xname<TAB>selector<TAB>host<TAB>port - -Where `selector` is the path to the resource and `X` is one of: - - Valid filetypes include: - 0 text file - 1 directory - 3 error message - 5 archive file (zip, tar etc) - 7 search query - 8 telnet session - 9 binary file - g GIF image - h HTML file - i info text - I generic image file (other than GIF) - d document file (ps, pdf, doc etc) - s sound file - ; video file - c calendar file - M MIME file (mbox, emails etc) - -There are a couple more special chars for that first line character. -Take a look at docs. - -So now the terminal lovers can find this site at gopher://onna.be/ - ---- -[1]: https://en.wikipedia.org/wiki/Gopher_(protocol) -[2]: https://github.com/kimholviala/gophernicus -[3]: https://github.com/kimholviala/gophernicus/blob/master/README.Gophermap - -Last updated: XXlastXX diff --git a/content/ipv6-config-he.md b/content/ipv6-config-he.md @@ -1,170 +0,0 @@ -title: IPv6 setup when your provider doesn't give a shit. -author: paco -date: 2018-11-09 -css: style.css - -XXmenuXX - ---------- -# IPv6 setup when your provider doesn't give a shit. -2018-11-09 - -This is a small guide to set up IPv6 via [HE][1] tunnel on a mostly -"unixy" environment. - -I've been thinking to play with the new IP version for a while, but -never really get into it until a couple of months ago. - -Sadly most internet providers out there (at least the ones serving -residential buildings) don't give a shit about IPv4 exhaustion or IPv6 -implementation. My provider is one of those. And I could not find in my -area one that provides native IPv6. - -There are other options. The one that came to mind (I've read about it -some time ago) was using [Tunnelbroker][2]. - -That's a 6-in-4 tunnel operated by Hurricane Electric. There are more -companies/projects offering this, here's a [list][3]. - -The process with HE is pretty simple. First one has to register on their -website and then create a tunnel. -This process involves choosing a endpoint server to tunnel your v6 -traffic. Choose one that's "close" to you in internet terms (that -basically means few hops, low latency. `traceroute(8)` and `ping(8)` are -your friends). - -You'll be then assigned a `/64`. Two really, one is for the tunnel itself. -But I won't be using them really (well, just for the tunnel). More on -that later - -On their website they have lots of example configurations. Just choose -your poison and they will provide basic instructions on how to set it -up. - -I wanted to set up this for my entire home/office network. I have a -small fanless OpenBSD machine acting as a router, so the instructions -are super simple: - - ifconfig gif0 tunnel 1.2.3.4 216.66.84.42 - ifconfig gif0 inet6 alias 2001:470:aaa:aaa::2 2001:470:aaa:aaa::1 prefixlen 128 - route -n add -inet6 default 2001:470:aaa:aaa::1 - -With just this, my router has IPv6 connection to the world ! -In this example `1.2.3.4` is my real IPv4 and `2001:470:aaa:aaa/64` is the -range assigned for the tunnel. As said earlier they assign another `/64` -so you can use it on your internal network. - -But, they also offer `/48` just in case you want to create different -subnets and do proper IPv6 auto configuration. You can ask for it once -you complete the registration and successfully establish the tunnel. - -It's still shocking to me that they deliver that prefix ... that means -they just route to you 65536 (+2) /64s ... nuts ! - -Anyway, the goal then is having the tunnel set up permanently, assign a -`/64` to every internal vlan and enable router advertisement for those -too. - -On my OpenBSD machine goes like this: - -Create `/etc/hostname.gif0` (the tunnel interface): - - tunnel 1.2.3.4 216.66.84.42 - !ifconfig gif0 inet6 alias 2001:470:aaa:aaa::2 2001:470:aaa:aaa::1 prefixlen 128 - !route -n add -inet6 default 2001:470:aaa:aaa::1 - -Add IPv6 config for the vlans. Here is the full config of one of mine, -at `/etc/hostname.vlan10` - - inet 10.42.10.1 255.255.255.0 NONE vnetid 10 parent em1 description "cable" up - inet6 2001:470:bbb:cab::1 64 - group internal - -Note that I'm using now part of the `/48` -I'll configure a `/64` for every other vlan in my net. - -Now we'll use `rad(8)` so all the devices on the net have IPv6 -connectivity too. -Here's part of my `/etc/rad.conf` Have a look at `rad.conf(5)` for more info. - - interface vlan10 { - prefix 2001:470:bbb:cab::/64 - dns { - nameserver 2001:470:bbb:cab::1 - search home.my.domain - } - } - -That's nice because we can set up `AAAA` records on a real domain, and HE -provides reverse DNS too ! - -Remember to enable IPv6 forwarding in your router. On OpenBSD is done -via `sysctl(8)/sysctl.conf(5)` - - net.inet6.ip6.forwarding=1 - -Also, check your pf(4) configuration. Most likely you'll need to adjust -it. - -At this point most of the devices in your network will be negotiating -IPv6 auto configuration. I found out that Android and iOS phones do that -automatically, and prefer v6 if present. All linux boxes using `dhcpcd(8)` -will work automatically too. -On Macs I found out that some were configured to take v6 config if -possible and others have it disabled, so just "switch it on" and you're -good to go. - -I have a couple of machines that act like servers, so I needed to set up -ip configuration manually there. Check your OS documentation on any -case. - -My main workstation runs OpenBSD too, so that was simple to set up. -On my `/etc/hostname.em0` - - dhcp - inet6 autoconf - -Also, tell the system resolver to prefer v6 over v4 if you want. On -`/etc/resolv.conf.tail` - - nameserver 2001:470:bbb:cab::1 - lookup file bind - family inet6 inet4 - -And that's it ! It was easier than expected ! - -A couple of caveats, though. - -Network latency could be a bit higher, depending on how packets get -routed to your tunnel server, etc. In my case, oddly enough, most times -latency is better through the tunnel ... which does not speak so well -about my internet provider right ? - -Also, speed may be an issue depending on your current connection. In -theory there's no speed limit on the tunnel. I have 200/200 Mbps here, -and I get about 65/65 Mbps through the tunnel easily. Which is more than -ok for my tests. But it varies in time. I guess they could have load -issues at some point. - -Besides, Netflix and other streaming services are not happy with you -using those ip ranges. You'll see the same error you get when you try to -use most vpns on the market ... So basically you may have problems with -any service that controls you to the extreme and cares about where you -connect from. The lesson here, don't use those services :-P - -And that's all folks ! -With some kind-of-simple steps one can have billions of public routable -ip addresses to play with at home/office/whatever for free. - -Another cool thing. HE has this [IPv6 Certification][4]. Is not that hard -if you take some time to do it and you'll learn a lot in the process. -Besides, they will send you a super nerd t-shirt when you complete all -levels ;-) - ------ -[1]: http://he.net/ -[2]: https://tunnelbroker.net -[3]: https://en.wikipedia.org/wiki/List_of_IPv6_tunnel_brokers -[4]: https://ipv6.he.net/certification/ - -Last updated: XXlastXX diff --git a/content/long-wireless-links-and-monitoring.md b/content/long-wireless-links-and-monitoring.md @@ -1,347 +0,0 @@ -title: Long Wireless links and monitoring. -author: paco -date: 2019-07-19 -css: style.css - -XXmenuXX - ---------- -# Long Wireless links and monitoring. -2019-07-19 - -## Intro - -Some time ago I built 2 [P-t-P][1] links between some family members' buildings. - -Thing is that my brother and my sister live in an area with no coverage from -traditional ISPs, but that is quite close (5.5km on a straight line, with no -obstacles) to my parent's which have good coverage (even FTTH) and plenty of -providers to choose from. - -This project has grown _organically_ so to speak, and the requisites kept -changing. - -That, and my lack of experience on the subject make all this far from an -optimal solution. - -In the end it has been working for almost 3 years now. This is an attempt to -document all the infrastructure and the bits and pieces used so I do not forget -about it and maybe it can be of use to somebody else. - -## First steps and research - -As I said, I knew nothing about this before tackling the project. I have some -solid knowledge about networking, but I knew little about long (for me) -wireless links, antennas, propagation and a bunch of other stuff I did not know -existed, so I had to do some research. - -If you want to do something like this, is better to plan ahead. See what the -requisites are and start digging. - -Some things to take into consideration are: - -* Budget. This is an important one in this scenario, as this is for personal - use only. -* Distance between the endpoints of the link. Modern hardware (more on my - choice later), can easily cover 10km or maybe more, but read the - manufacturer's datasheet and look for output power, antenna gain and - sensitivity. And always take their numbers with a grain of salt, as they - are usually tested on ideal conditions you won't encounter. You'll find - later a way to calculate the ideal numbers to have an estimate. -* Obstacles. There has to be perfect clear vision between endpoints. Wireless - communications, especially WiFi either on 2.4GHz or 5GHz, are very - sensitive to obstacles. Even partial cover can have a big impact on link - quality. And clear vision does not mean _"I can see a single point in the - distance"_, there's this thing called [Fresnel zone][2], under some - atmospheric conditions or spectrum saturation it will give you a lot of - trouble. -* Materials. Don't be cheap. This will have to resists the outdoor conditions - for as long as possible. -* Neighbours and regulations. There's the legal part (RF regulations in your - country and things like that) and the _"social"_ part, in this case my - family does not live in detached houses but on apartments, so that has to - be taken into consideration if there are any rules about this. -* Infrastructure. And by that I mean all the necessary to be able to install - the antennas, route the cables, install connectors, etc. I'm not only - talking about tools, but also access to the best spots to put the antennas, - etc. -* Antenna location. As a rule of thumb, the higher the better. But this - depends a lot on your particular situation. It deserves some thought. -* Spectrum saturation. Wifi is ubiquitous now. That may be a challenge for - any installation specially on urban areas. Ideally, you should check how - _crowded_ the spectrum is, but this is usually pretty difficult for - amateurs without special equipment. Some antennas have a built in spectrum - analyser, but it may perform badly. - -## Materials - -This is a list of materials I choose and why I choose them. It is short, as it -is really an easy installation. - -### Antennas - -I ended up using [Ubiquity PowerBeams][2] to create the 2 links. Four in -total, 2 for each link. - -I was looking for some reputable manufacturer trying to avoid problems in the -future. Also, I wanted something as simple as possible. This kind of antennas -have the _"emitter/receiver"_ and the antenna all in the same device. So no -special connectors to be crimped, virtually no losses on cables, just an easy -[PoE][4] setup from the house to the rooftop. - -Also, this antenna has an easy to setup web interface _and_ an SSH server that -leaves you in a busybox with some proprietary commands that are pretty handy -for automation and data collection. - -There are newer models now and other manufacturers. Do your research, read on -forums and all the usual stuff. I can say those work for this setup with minor -issues. - -If you know something about this subject you may be wondering why I did not use -something with a wider angle on the _"access point"_ side and use just 3 -antennas instead of 4. Truth is, I tried, but I had some problems with the 2nd -link giving poor performance. Not being an expert on this I can only guess -that the partial obstruction on the LOS (line of sight) path for the second -link was the cause of the poor performance, specially on bad weather days (WiFi -is pretty sensitive to heavy rain) and episodes of spectrum saturation. - -Creating a separate link with a dedicated pair of antennas improved the -situation a lot. - -### Cables - -As the antennas only need a network connection, we only need Ethernet cable. -Be sure that is CAT5e or better. - -Always use cable rated for outdoor use. Regular network cable will not last -long exposed to rain and the sun's UV. I went for [this one][5] because it was -available at the time on Amazon. - -### Connectors - -Don't go extra cheap on this, but anything with reasonable quality will do -here. The antennas are built in a way that the connectors are never exposed, -so this part is not that critical. - -### Antenna pole and other hardware - -I cannot say much about this. What to buy here depends a lot on your -particular setup. Remember that the higher the better for the antennas, and -remember wind is a thing ... you do not want it to fly away like a plastic bag. - -## Build steps - -This is a list of the build steps I took. I started checking the list -mentioned on the [First steps](#first-steps-and-research) section. -Specifically the location of the antennas and the clear line of sight. - -I have to admit that I did a sloppy job on the second link, because I did not -know about the [Fresnel zone][2] back then, but there's some things you can do -to mitigate is effects. - -### Calculate signal strength - -There's a simple way to calculate the signal strength you should see on the -other side of the link (on ideal conditions). This can be taken as a reference -to see if the setup is viable and what conditions and speed negotiation you can -expect between the 2 endpoints of the link. - -The simplified formula to calculate the signal is: - -``` -emitterPower + emitterGain - signalLoss + receiverGain -``` - -I say this is the simplified formula, because it does not take into account -loses on cables and connectors, that's because I choose to use a _"all in one -packet"_ type of antenna, so that makes no sense. This is a huge advantage for -a beginner. Also, because I only take into account the free space loss and not -any other kinds of loss, that would be a lot more difficult to calculate. That -was sufficient for me anyway, as the conditions of line of sight are pretty -good. - -To calculate signal loss, this is the formula: - -``` -loss = 20*log((4*π*d)/λ) -``` - -Being `d` the distance between the 2 endpoints in meters and `λ` the -wavelength, also in meters. If you do not remember how to calculate the -wavelength from the frequency is just: - -``` -λ = C/f -``` - -Being `C` the speed of light in meters per second and `f` the frequency in -Hertz. - -So, as an example, let's say I choose channel `137` which is `5685 MHz`, and -the 2 endpoints are 5.2km apart. That gives us a signal loss of `121.85 dB`. - -According to the antenna datasheet the transmission power is `5 dBm`, the gain -of the antenna is `25 dBi` (that's on average I guess). So putting all that -together I should get on the other end `-66.86 dBm`. This works both ways in -this case, so now we have to check sensitivity. Again according to the -datasheet, there's no problem in any modulation negotiation with this kind of -signal strength (in theory, so to be on the safe side add at least `-3 dB` to -your results). - -### Physical setup and alignment - -With the theory calculations out of the way, knowing that is possible, the fun -part starts, we have to get on the roof now and install the antennas. - -Of course I won't be saying much about this, as this is different for every -single installation. Suffice to say, I had a _"pretty fun time"_ up on ladders -and climbing to places not meant to be climbed ... - -With the antenna installed, before attaching it securely to the pole, it has to -be aligned the right way. - -On the datasheet you'll find radiation plots for your model. The principle is -simple, those are 2D representations of the radiation lobes of the antenna, and -the loss referred to the total gain. So basically you want to point them to -one another as perfectly as possible, specially for parabolic antennas, which -have a very narrow beam. - -Those radiation plots confused me at first as, in case of the PowerBeam there -are 4 of them "Vertical Azimuth", "Vertical Elevation", "Horizontal Azimuth" and -"Horizontal Elevation". This did not make any sense for me in the beginning, -as the azimuth is an horizontal angle and elevation is a vertical one. It -drove me nuts. It turns out it refers to both polarisations of the signal that -those devices create ... Once you understand that is easy, they are just the -same measurement but times 2, one for each polarisation. - -Once you know how many angles you have before starting to loose signal, and -with a bit of the good old trigonometry, you know your margin of error when -pointing the antennas to each other. - -I did this standing behind the antenna and looking as if my line of sight was -the beam. With some fiddling, that should be enough for the horizontal -alignment. For the vertical one, it's easier, because the error margin is -pretty big compared to the distance to the ground, even if you're on a tall -building (again, trigonometry, that angle at 5km is some meters ...). Anyway -with the help of some online tool you can calculate that easily to make it as -precise as possible (search for "antenna downtilt calculator" on your favourite -search engine). - -### Network diagram and configuration - -With the antennas installed, it's time for some configuration. - -This is a basic diagram of the network setup: - -``` - 192.168.1.6/24 - +--------+ - | Bro. | - 192.168.1.2/24 192.168.1.4/24 | Router | - +---------+ +----------+ +--------+ - | Antenna | | Antenna | / 192.168.10.1/24 - ----| AP1 |+++++++++| ST1 |--- - 192.168.1.1/24 ---/ +---------+ +----------+ - +---------+ -+---------+ -| ISP | -|Internet |-/ | Router | -+---------+ +---------+ - | --\ +---------+ +-----------+ - \ --\ | Antenna | | Antenna | - \ --| AP2 |+++++++++| ST2 |-\ - | +---------+ +-----------+ -\ 192.168.1.7/24 - \ 192.168.1.3/24 192.168.1.5/24 +---------+ - +------------+ | Sis. | - | Rpi | | Router | - | Monitoring | +---------+ - +------------+ 192.168.10.1/24 - 192.168.1.10/24 -``` - -All are cable connections but the `++++` ones, which are the 5km links. - -On the routers/APs at the end of the chain I used the same network segment for -both, as hey will be isolated and do NAT. I did this because I have little -control over the ISP router. It is _"reset to defaults"_ from time to time and -that caused me problems before. So setting static routes would be a pain to -maintain. That produces double NAT on my siblings', but that's a small price -to pay for having a stable setup. - -Yes, I know that's a shitty thing to do for an ISP (they break your dhcp -reservations and port forwarding), but most of the ISPs where I live are the -biggest idiots and do the dumbest stuff you can imagine, so that's not even -something for them. - -The PowerBeams are configurable via a web interface that is pretty intuitive. -They can also be configured via an SSH access and editing a text file + some -commands. - -Some things I did: - -* enable WDS (transparent bridge mode), so I see the MAC addresses of all the - chain from my monitoring station. That helps on debugging if something - network goes wrong. -* I enabled SNMP for monitoring, SSH server for access (with public keys) and - NTP so the antennas have the right time (good for logs). -* All 4 antennas are set up on bridge mode. -* The ones connected to the ISP router are set up as "Access Point" and the - other 2 as "Stations" -* The antenna startup wizard asks you for country location. That's because - they apply the necessary regulation restrictions automatically. Do not - cheat here, you can have problems with your local authorities. Besides, if - you do not have good signal within the power output regulations chances are - you're doing something wrong or the conditions of line of sight, etc. are - not really good, so it won't matter and you'll be breaking the law for - nothing (and probably causing problems to other antennas and - installations). - -If you prefer the command line to configure the antennas, log into them via SSH -and edit the file `/tmp/system.cfg`. Then save to `NVRAM` with the command -`cfgmtd -w`. Then reset with `/usr/etc/rc.d/rc.softrestart force`. - -I do not recommend that method at the beginning, until you get familiar with -all the options and configurations possible. You can make a pretty big mess. - -As I said earlier, those antennas have a sort of spectrum analyser you can use -to determine which channel is less busy. It uses some java applet (yes, I know -...) and it has been broken in 2 occasions on some firmware updates. But it -can be of assistance if your spectrum is really busy. - - -### Performance tests - -There are 2 ways to easily test the throughput of the links. The web interface -has a "speed test" built in. You have to put the credentials of the other end -and it can test TX, RX or both. - -The other way (that I like the most) is `iperf(1)`. The antennas have installed -a basic implementation of that tool, so log into the antenna on the other end, -and use `iperf(1)` either as server or client to test both sides of the -communication. - -Play a bit with the channel width. More channel width allows for faster -transfer rates, but a narrow channel increases stability. - -I ended up using `20 MHz` for one of the links and `10 MHz` for the other. -That last one is the one with less than ideal LOS situation. In the end -reducing the channel width and choosing the least busy channel did the trick -and I could get a stable link. - -In the end for the first link I get around `32Mbps` symmetrical. The second -link is a lot more variable depending on the conditions and the interferences -from other stations. I get up to `17Mbps` symmetrical, and is usually more -than `12Mbps`, but on worst case scenario it can get as low as `6Mbps`. Which -is still enough to watch online videos at `1080p` with today's compressions and -is more than enough to do any kind of browsing, email and whatever ... so -I guess is enough. - -### Monitoring - ----- -[1]: https://en.wikipedia.org/wiki/Point-to-point_(telecommunications) -[2]: https://en.wikipedia.org/wiki/Fresnel_zone -[3]: https://www.ui.com/airmax/powerbeam/ -[4]: https://en.wikipedia.org/wiki/Power_over_Ethernet -[5]: https://www.konigelectronic.com/computer/networking/network-cable-reel-cat5e-futp-100-m-black-solid-55896639 - -Last updated: XXlastXX diff --git a/content/nfs-performance-improvements-openbsd.md b/content/nfs-performance-improvements-openbsd.md @@ -1,53 +0,0 @@ -title: Performance improvements on NFS mounts on OpenBSD -author: paco -date: 2018-11-18 -css: style.css - -XXmenuXX - ---------- -# Performance improvements on NFS mounts on OpenBSD -2018-11-18 - -Those are simple notes on how to increase performance (read basically) -on my OpenBSD desktop again my NAS at home. - -The NAS exports a set of folders via various protocols. AFP for the -Macs, NFS for OpenBSD and maybe Linux and Samba for everything else -(basically one Ubuntu I use as media center). - -It runs FreeBSD, and the performance is generally good on all protocols, -limited more or less by the speed of the link 1Gbps but OpenBSD was -reporting some low values, in the order of 390Mbps read and 60 Mbps -write. - -A quick look at the OpenBSD list archives gives me a nice [thread][1] that -explains a lot. - -After some playing around, I applied the following options to the NFS -mount points: - - -T/-U To force TCP or UDP respectively, see below - -3 To force NFSv3 (this is unnecessary as is the default) - -a 4 readahead value set to the max. See mount_nfs(8) - -r 32768 readsize. Again see mount_nfs(8) - -w 32768 writesize. same thing. - noatime I set this up always on network resources. - -Oddly enough, I get more stable results (specially on writes) using TCP -instead of UDP ... - -On TCP that read speed is almost saturating the link, ad 890Mbps and -write speed is way better (enough for me anyway) at 410Mbps - -On UDP read speed is even better around 905Mbps but write speed is poor -and inconsistent at about 128Mbps - -So in the end I end up using TCP. Maybe I'll take a closer look in the -future to see if I can improve write a little bit, but it's OK for me at -this stage. - ------ -[1]: https://marc.info/?l=openbsd-misc&m=146130062830832&w=2 - -Last updated: XXlastXX diff --git a/content/partkeepr-barcodes-and-TME.md b/content/partkeepr-barcodes-and-TME.md @@ -1,83 +0,0 @@ -title: Barcodes, Partkeepr and parts providers(TME) -author: paco -date: 2018-03-08 -css: style.css - -XXmenuXX - ---------- -# Barcodes, Partkeepr and parts providers(TME) -2018-03-08 - -Electronic parts are small ... and they get smaller and smaller when you -go down the rabbit hole of SMD components. They are also really difficult -to organize and catalogue. There are useful tools like [Partkeepr][1] to -help you keep things tidy and, most importantly, don't buy things twice -because you can't find them or you don't remember where the hell they -are (or even don't remember that you have them). - -The only drawback to that is that you have to manually insert all the -parts that you buy ... which is tedious. - -I basically get my parts for 4 places: - -* The _slow boat from China_, when piece is important and time is not. -* Ebay, basically same thing, although sometimes there are sellers in - Europe, which is nice ! -* [TME][2], a polish distributor with fairly good prices and good catalogue - that I tend to use when I need to be sure what I'm buying. -* And [Farnell/Element14][3], when I need something that I cannot find - anywhere else ... - -It turns out that the last 2 have good APIs to query their catalogue. And -specifically TME adds a little iQR code to all their packages with some -info. - -With any old webcam you can find, and [zbar][4], you can extract the info -on that iQR code easily, and dump it to `stdout`. It looks something -like this (this is a little 12V fan): - - QTY:1 PN:HA50151V4 MFR:SUNON MPN:HA50151V4-000U-999 PO:xxxxxx/x https://www.tme.eu/details/HA50151V4 - - where: - - FIELD NAME Desc - 0 QTY Quantity - 1 PN Part Number - 2 MFR Manufacturer - 3 MPN Manufacturer part number - 4 PO Order Number (at TME) - 5 Url of the product at vendor(TME) - - -That's easy to parse, and contact TME's API for more info. - -I've put together a little python3 script that takes that from `stdin` -and makes all the necessary calls (to TME and then to Partkeepr), so I -don't have to enter my TME orders by hand anymore. You can find it -[here][5] - -You'll need a token and secret from the distributor. So go to their -developer's [page][6] and sing in. - -It downloads the datasheets too (if they have any) and uploads them to -Partkeepr. If the item is already in the db, it just increments the -stock. - -On the git page you can find more info, but it's really easy to use, -just pipe the output of zbar to the script like this: - - zbarcam --raw /dev/video0 | ./parteye.py - -If I order something from Farnell I'll check if they do something -similar, so I can adapt the script. - ------ -[1]: https://www.partkeepr.org/ -[2]: https://www.tme.eu/ -[3]: http://farnell.com -[4]: http://zbar.sourceforge.net -[5]: https://git.onna.be/parteye/ -[6]: https://developers.tme.eu - -Last updated: XXlastXX diff --git a/content/pass-terminal.md b/content/pass-terminal.md @@ -1,62 +0,0 @@ -title: Password management in the terminal done right. -author: paco -date: 2017-10-10 -css: style.css - -XXmenuXX - ---------- - -# Password management in the terminal done right. -2017 - -_Update_: Some time ago I wrote a little more detailed intro to `pass` on the -[tilde.institute wiki][2] - -I spend most of my time in front a computer in the terminal ... I'm used -to it, and I like it a lot. There's nothing (well, almost nothing) a -terminal app or a combination of apps can't do (way better some times -that its graphical counterparts). - -One of those apps that's particularly useful is [pass][1]. A password -manager for the terminal. - -Is quite simple. It creates a hierarchy of folders and files in -`$PASSWORD_STORE_DIR` (`~/.password-store` by default) and encrypts them with -your GPG key. - -It can copy the recovered passwords to the clipboard, has `bash` and -`zsh` completion. Can generate random passwords for you and more ... - -You can also create multi-line _stores_ with extra information, but just -the first line will be copied to the clipboard when you use `-c`. - -They have a great web page explaining all that, and a really good man -page, so there's no excuse to have ugly methods for managing your -passwords ... or no methods at all ! - -The things I use the most: - - pass -c site/foo.com/username - -This one gets the password for `username@foo.com` and puts it on your -clipboard. - - pass generate -c email/me@foo.com - -This one generates a random password, stores it on `email/me@foo.com` -and copies it to the clipboard. Pretty useful when you're singing in to -a new service. - - pass edit foo/bar/baz - -This one edits one of your entries. Mind that generate won't ask for -password, as you're encrypting to your GPG public key, but edit or show -will. It's a good idea to have GPG agent setup, so you can control -how/when passwords are requested. - ------ -[1]: https://www.passwordstore.org/ -[2]: https://wiki.tilde.institute/w/pass - -Last updated: XXlastXX diff --git a/content/raidz-disk-change.md b/content/raidz-disk-change.md @@ -1,94 +0,0 @@ -title: ZFS RAIDZ disk change -author: paco -date: 2018-11-13 -css: style.css - -XXmenuXX - ---------- -# ZFS RAIDZ disk change -2018-11-13 - -Here are some notes in order to change a failing disk on a RAIDZ pool. -This has been tested on FreeBSD 11.2. It may work with other versions, -but check `gpart(8)`, `zpool(8)` and the handbook to be sure. - -My NAS runs FreeBSD 11.2 with zroot, 4x3TB disks in raidz1. -Some days ago 1 of those disks started to report quite a few _smart_ -errors. ZFS itself did not report any errors, but I prefer to change the -disk while it still works. It's probably faster (copy over re-build) -and safer, as one does not face the possibility of a failing disk while -rebuilding the RAID. - -In this particular case `ada2` was failing, and ada4 was the new disk. -This will change once the failing disk is removed, but I don't care as I -use gtp labels. - -I don't like GPT GUID labels nor DiskID labels (although I see the point -on this latter ones when you have a bunch of disks ...). So, I have this -on `/boot/loader.conf` - - kern.geom.label.gptid.enable="0" - kern.geom.label.disk_ident.enable="0" - -First thing is to create thg GPT partition table: - - gpart create -s GPT ada4 - -And replicate the same partition scheme on the new disk (in my -particular case replacement disk and replaced disk are the same model): - - gpart backup ada2 | gpart restore -F ada4 - -This only replicates the partition scheme, but not the labels. So that -has to be done manually: - - gpart modify -i 3 -l zfs4 ada4 - gpart modify -i 2 -l swap4 ada4 - gpart modify -i 1 -l gptboot4 ada4 - -As you can see on my schema I have a boot partition on each disk, a swap -partition an another partition which is part of the zpool. - -At this time, we're ready to replace the disk: - - zpool replace zroot gpt/zfs2 gpt/zfs4 - -This can take a lot of time. It all depends on your hardware. In my case -it took over 10h. - -Is a good idea to setup now the bootloader in place on the new disk: - - gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada4 - -Once finished everything is back to normal: - - pool: zroot - state: ONLINE - scan: resilvered 2.15T in 10h23m with 0 errors on Tue Nov 13 04:31:35 2018 - config: - - NAME STATE READ WRITE CKSUM - zroot ONLINE 0 0 0 - raidz1-0 ONLINE 0 0 0 - gpt/zfs0 ONLINE 0 0 0 - gpt/zfs1 ONLINE 0 0 0 - gpt/zfs4 ONLINE 0 0 0 - gpt/zfs3 ONLINE 0 0 0 - - errors: No known data errors - -As a bonus, those commends can help a lot getting information about the -disks, partitions and status: - - zpool status - gpart show - gpart backup <provider> - camcontrol devlist - -Take a look at the respective man pages before executing anything on -your machine ! - ------ - -Last updated: XXlastXX diff --git a/content/self-hosted-xmpp-server.md b/content/self-hosted-xmpp-server.md @@ -1,263 +0,0 @@ -title: Self hosted XMPP server (on OpenBSD) -author: paco -date: 2019-04-25 -css: style.css - -XXmenuXX - ---------- -# Self hosted XMPP server (on OpenBSD) -2019-04-25 - -Tested on OpenBSD 6.5 (prosody version 0.11.2) - -## Intro - -Self-hosting an instant messaging service is quite simple. This guide shows how -to do it using OpenBSD as a base system and XMPP as the messaging protocol. - -The end result is an End-to-End encrypted chat system for 1:1 or multi-user -conversations. - -The software used for the server is [prosody][1], and it's all based on -[this guide][2]. - -For the clients, I've tried [Gajim][3] for the desktop (works for Windows, -Linux and *BSD), [Conversations][4] on the phone (Android) and [profanity][5] -on the terminal (works almost everywhere). There's a client for iOS called -[ChatSecure][8], but I have not tried it. - -## Rationale - -I used to host my messaging services back in the day. People stopped using this -for some reason, and then came all the Whatsapp and co. So all that was -forgotten. - -Although I never used whatsapp, on recent times I've been testing some instant -messaging systems, but none of them were good enough. In the end, all rely on -central systems, often owned by companies that have to make money from -somwhere. Most of the times is you (one way or another) even if they say the -service is free. - -I wanted something simple, client independent, secure (well, as secure as -possible ...), easy to use from the client point of view and easy to manage -from the server part. My goal is to replace things like Signal that I use with -my family and friends. - -XMPP is federated, just like email is. And with recent extensions like easy to -use End-to-End encryption and http file sharing it's a viable solution for -resilient and secure instant messaging system, that does not spy on you (no -more than encrypted email for instance). - -For now is not a complete replacement, as it does not provide VoIP, but is a -start. I may look for voice alternatives or dig deeper for a jabber client that -supports voice. - -## Previous steps (DNS and TLS) - -Some DNS configuration is needed for this guide. If you are not using file -uploads or multi-user chat, then is probably fine if your root dns name points -to the machine that will host the xmpp server. If not, you'll have to define -some SRV records, and also any record you may use for the mentioned services. -It may look like this (config depends on your DNS provider): - - _xmpp-client._tcp 1800 IN SRV 5 0 5222 server.mydomain.com. - _xmpp-server._tcp 1800 IN SRV 5 0 5269 server.mydomain.com. - -This will tell xmpp clients and other servers trying to reach your accounts -where (host and port) to knock. - -In this particular case I configured also multi-user chat and http file -uploads, so I defined `uploads`, `proxy` and `groups` as `CNAME` of the -server's `A` record. - -I also configured `acme-client(1)` and `httpd(8)` to get certificates from -letsencrypt, so all communications client/server and server/server is -encrypted. - -How to do that is out of the scope of this guide, just read the man pages, it's -quite easy to do. The only detail to take into account is that is better to -have all the domains/subdomains with its own cert and into separated folders -containing the certificate and the private key. This important for certificate -import on prosody later on. So I ended up configuring it to store certs on a -structure like: - - /etc/ssl/letsencrypt/ - |-- mydomain.com - | |-- cert.pem - | |-- fullchain.pem - | `-- privkey.pem - |-- groups.mydomain.com - | |-- cert.pem - | |-- fullchain.pem - | `-- privkey.pem - ... - -## Server install - -Install the server is as easy as: - - $ doas pkg_add prosody - -## Server config - -So here comes the fun part. - -First you should get the community modules. Some of them provide functionality -that is needed on any modern IM system. - -The way to do that is cloning the [mercurial][6] repository. I did not want to -have it installed on my server, so I cloned it on my desktop machine and synced -to the server. So, on my desktop I did: - - hg clone https://hg.prosody.im/prosody-modules/ prosody-modules - -Then I uploaded it to `/usr/local/lib/prosody-modules/` on the server. -Here's the important parts I changed from the config files and why: - -Community modules location: - - plugin_paths = { "/usr/local/lib/prosody-modules" } - -List of globally enabled modules: - - modules_enabled = { - "roster"; -- Allow users to have a roster. Recommended ;) - "saslauth"; -- Authentication for clients and servers. Recommended if you want to log in. - "tls"; -- Add support for secure TLS on c2s/s2s connections - "dialback"; -- s2s dialback support - "disco"; -- Service discovery - "carbons"; -- Keep multiple clients in sync - "pep"; -- Enables users to publish their mood, activity, playing music and more - "private"; -- Private XML storage (for room bookmarks, etc.) - "blocklist"; -- Allow users to block communications with other users - "vcard"; -- Allow users to set vCards - "version"; -- Replies to server version requests - "uptime"; -- Report how long server has been running - "time"; -- Let others know the time here on this server - "ping"; -- Replies to XMPP pings with pongs - "register"; -- Allow users to register on this server using a client and change passwords - "mam"; -- Store messages in an archive and allow users to access it - "admin_adhoc"; -- Allows administration via an XMPP client that supports ad-hoc commands - "server_contact_info"; -- Publish contact information for this service - "vcard4"; - "vcard_legacy"; - "smacks"; -- XEP-0198: Stream Management, keep chatting even when the network drops for a few seconds - "csi_simple"; - "bookmarks"; - "cloud_notify"; -- XEP-0357: Push Notifications. - } - -Disable registration, as this will not be a public server. This is the default, -but just check it just in case. - - allow_registration = false - -Force clients to use encrypted connections - - c2s_require_encryption = true - -Force servers to use encrypted connections. - - s2s_require_encryption = true - - -Force certificate authentication for server-to-server connections. This may -bring problems with servers that use self-signed certificates. Today nobody -should be using that, as there are alternatives like letsencrypt but, if you -have some server you want to talk to that uses self-signed certs, check -`s2s_insecure_domains` - - s2s_secure_auth = true - -Location of directory to find certificates in (relative to main config file), -on OpenBSD that's `/etc/prosody/certs` - - certificates = "certs" - -Virtual host. You can have many, for many domains. In my case this is just one -personal domain. I limited the uploads to 9MB, but you can set up any other -limit. Keep in mind that there's a 10MB limit for `http_max_content_size` - - VirtualHost "mydomain.com" - Component "uploads.mydomain.com" "http_upload" - http_upload_file_size_limit = 1024 * 1024 * 9 -- 9MB upload limit - Component "groups.mydomain.com" "muc" - modules_enabled = { "muc_mam", "vcard_muc" } - Component "proxy.mydomain.com" "proxy65" - -At this point you can import the certificates you got from letsencrypt (or from -any other CA), with the command: - - prosodyctl --root cert import /etc/letsencrypt/letsencrypt - -That will copy all needed files to `/etc/prosody/certs` so they are accessible -to the prosody daemon. Now you can start the daemon: - - doas rcctl start prosody - -To make it permanent on boot, add it to the `pkg_scripts` on -`/etc/rc.conf.local`. - -Also remember to open ports on the firewall (pf or any other you may have in -front of your server). They are: - - 5000 --> for proxying large file transfers between clients - 5222 --> for client to server - 5269 --> server to server - 5281 --> default https port for http file transfers - -## Add accounts and client config. - -In order to add an account to your new server just execute: - - prosodyctl adduser user@mydomain.com - -You'll be asked for the new password and that's it ! - -On the client side is usually enough to enter the jid (jabber id, in this -example `user@mydomain.com`) and the password. As we configured the necessary -dns records earlier, the client will discover to which server and port to -contact to. - -## OMEMO - -[OMEMO Multi-End Message and Object Encryption][7] is an extension to XMPP that -provides encryption for 1:1 and multi-user chats. - -This is key for a secure chat system. Some of the most popular xmpp clients -already support it. Conversations, for instance, has it enabled by default. -Do not forget to set it up on your client. - -OMEMO trusts devices on first use, then you should check the key fingerprints -to see if the person you're talking to is who it claims to be. - -Is a good practice to publish those fingerprints on some place public, like you -would do with your GnuPG public key. In fact you could sign those to provide -some proof of ownership. - -On Conversations, for instance, you can later verify a contact fingerprint via -a QR code. From that moment no other key will be allowed for that contact if -you do not explicitly allow it. I think all clients should support that ... - -## Conclusion - -Now you should have a working XMPP server. It can not only be used for IM, but -also for notifications on your scripts using the libraries for your language of -choice. Here you have some examples in [perl][9], [python][10] and [golang][11] - ---- - -[1]: https://prosody.im -[2]: https://homebrewserver.club/configuring-a-modern-xmpp-server.html -[3]: https://gajim.org/ -[4]: https://conversations.im/ -[5]: http://www.profanity.im/ -[6]: https://www.mercurial-scm.org/ -[7]: https://en.wikipedia.org/wiki/OMEMO -[8]: https://chatsecure.org/ -[9]: https://metacpan.org/pod/Net::XMPP -[10]: https://lab.louiz.org/poezio/slixmpp -[11]: https://github.com/FluuxIO/go-xmpp - -Last update: XXlastXX diff --git a/content/teensy-midi-controller.md b/content/teensy-midi-controller.md @@ -1,92 +0,0 @@ -title: Teensy MIDI controller -author: paco -date: 2019-03-16 -css: style.css - -XXmenuXX - ---------- -# Teensy MIDI controller -2019-03-16 - -I recently discovered, and been playing with [VCV Rack][1]. This software -is just awesome. - -I knew about modular synthesizers because a friend of mine (dj and -musician) told me about it some years ago, but I never really got it. -With vcv rack you can understand how modular synthesis works, play with -it and learn a thing or two about music in general and analog signals. -It is pretty fun. Not to mention that real hardware modular is extremely -expensive and with this software option you can add as many modules as -your CPU can handle before start "glitching". - -One thing I do not like about software synths is the "abstraction". I -mean, you are point and click, so the experience is poor really, so I -thought to make a device to control some of the parameters of the -patches (that's modular jargon for a particular modular setup). - -Such devices do exist, they are called MIDI controllers, but I did not -want to spend much money on this, as I know nothing about music and they -are not super cheap. - -They send MIDI [commands][2], which is the industry standard for digital -music communication. In this case over USB instead of the traditional -serial over midi DIN cable. - -There are some easy ways to make such a device. Some Arduino compatible -development boards out there (like the [Teensy][3], LC in my case) can act -as a USB MIDI device and programming them to do basic stuff is really -easy. - -So, I got a Teensy LC (the cheapest I could find), 8 potentiometers and -4 buttons and connected them together. With a bit of [code][4] I had a -MIDI device sending MIDI CC (control) commands to the computer. Then I -just had to configure the MIDI-CC core module on vcvrack, and start -patching! - -This device is not limited to vcvrack. It can be used with any software -that accepts midi commands. - -The midi channel can be changed modifying this line on the code - - #define MIDI_CHANNEL 2 - -Same for the control commands on the pots and buttons: - - static const uint8_t potCC[NUM_POTS] = {1, 2, 3, 4, 5, 6, 7, 8}; - static const uint8_t btnCC[NUM_BUTTONS] = {11, 12, 13, 14}; - -The mode of the buttons can be one of momentary, latch or trigger and -can also be adjusted here: - - uint8_t btnMode[NUM_BUTTONS] = {MOMENTARY, TRIGGER, TRIGGER, LATCH}; - -Now I can pair real pots and buttons with some of my patch parameters -and play with it. Here's an [example][5] (yeah, I'm definitely not a -musician) - -I also designed a case for it using FreeCAD and printed it on my 3D -printer. The end result is not bad at all. I'll upload some pictures -when I have the time [here][6] - -The only problem with all this is that is highly addictive ... - -Let's see how it goes. - -Here you have more references for [Teensy USB MIDI][7] and VCV Rack -"howto's" ([1][8] and [2][9]) - -Have fun ! - ----- -[1]: https://vcvrack.com/ -[2]: https://en.wikipedia.org/wiki/MIDI -[3]: https://www.pjrc.com/teensy/ -[4]: https://git.onna.be/midi_controller/ -[5]: https://onna.be/files/vcvrack_test.mp3 -[6]: https://onna.be/files/midi_controller_pictures/ -[7]: https://www.pjrc.com/teensy/td_midi.html -[8]: https://www.youtube.com/channel/UCuWKHSHTHMV_nVSeNH4gYAg -[9]: https://www.youtube.com/channel/UCnZEv3hADF9ELOIwUNu6RVg - -Last updated: XXlastXX diff --git a/deploy.sh b/deploy.sh @@ -1,180 +0,0 @@ -#!/bin/sh - -set -eu - -htmlDir="./htmlOut" -gopherDir="./gopherOut" -force=0 - -for cmd in lowdown envsubst rsync; do - if ! command -v "$cmd" > /dev/null; then - echo "$cmd not found!" - exit 1 - fi -done - -usage() { - echo "$0 -d htmldir -g gopherdir [-f]" -} - -generate_html() { - orig=$1 - dest=$2 - last=$(TZ=UTC date) - menu=$(sed 's/"/\\"/g' templates/menu_template.html) - echo " - generating $dest" - tmpFile=$(mktemp) - lowdown -s -D html-skiphtml "$orig" > "$dest" - sed "s!XXmenuXX!${menu}!" "$dest" > "$tmpFile" - sed "s!XXlastXX!${last}!" "$tmpFile" > "$dest" - rm "$tmpFile" - test "$3" = "1" && touch generate_index_html.flag -} - -generate_html_index() { - articleList="" - last=$(TZ=UTC date) - date=$(TZ=UTC date '+%F') - menu=$(cat templates/menu_template.html) - for f in $1; do - mdFile=$(basename "$f") - file="${mdFile%%.md}.html" - title=$(grep -E '^title: ' "content/$mdFile" | sed 's/title: //') - item="<li><a href=\"$file\">$title</a></li>\\n" - articleList="$articleList$item" - done - eval "echo \"$(sed 's/"/\\"/g' templates/index.html)\"" \ - 2> /dev/null \ - 1> "$htmlDir/index.html" -} - -generate_gopher() { - orig=$1 - dest=$2 - last=$(TZ=UTC date) - echo " - generating $dest" - tmpFile=$(mktemp) - sed '1,/---------/d' "$orig" > "$tmpFile" - sed "s!XXlastXX!${last}!" "$tmpFile" > "$dest" - test "$3" = "1" && touch generate_gophermap.flag -} - -generate_gophermap() { - articleList="" - last=$(TZ=UTC date) - for f in $1; do - mdFile=$(basename "$f") - file="${mdFile}.txt" - title=$(grep -E '^title: ' "content/$mdFile" | sed 's/title: //') - item="0$title /$file onna.be 70 -" - articleList="$articleList$item" - done - export last - export articleList - envsubst < templates/gophermap > "$gopherDir/gophermap" -} - -copy_phlog_entry() { - cp "$1" "$gopherDir/phlog/" - test "$2" = "1" && touch generate_phlogmap.flag -} - -generate_phlogmap() { - entryList="" - last=$(TZ=UTC date) - for f in $1; do - file=$(basename "$f") - title=$(echo "$file" | sed 's/_entry\.txt//') - item="0$title /phlog/$file onna.be 70\\n" - entryList="$entryList$item" - done - eval "echo \"$(cat templates/phlogmap)\"" \ - 2> /dev/null \ - 1> "$gopherDir/phlog/gophermap" -} - -while getopts d:g:f opt; do - case $opt in - d) htmlDir="$OPTARG";; - g) gopherDir="$OPTARG";; - f) force=1;; - *) usage ; exit 2;; - esac -done - -mkdir -p "$htmlDir" "$gopherDir" - -# copy static content to both output dirs -echo "* sync static content" -rsync -a static/ "$htmlDir" -rsync -a static/ "$gopherDir" - -# generate html and gopher content from md -echo "* generate new content" -sortedArticles=$(grep -E '^date: ' content/*md | \ - sed 's/date: //' | sort -t: -k2 -r | cut -d':' -f1) -echo "$sortedArticles" | while read -r f; do - mdFile=$(basename "$f") - filename=${mdFile%%.md} - fileMtime=$(stat -f %c "$f") - if [ ! -f "$htmlDir/$filename.html" ] || [ "$force" = "1" ]; then - echo " - $htmlDir/$filename.html does not exist" - generate_html "$f" "$htmlDir/$filename.html" 1 - else - htmlMtime=$(stat -f %c "$htmlDir/$filename.html") - if [ "$fileMtime" -gt "$htmlMtime" ]; then - echo " - $f newer than $htmlDir/$filename.html" - generate_html "$f" "$htmlDir/$filename.html" 0 - fi - fi - if [ ! -f "$gopherDir/$mdFile.txt" ] || [ "$force" = "1" ]; then - echo " - $gopherDir/$mdFile.txt does not exist" - generate_gopher "$f" "$gopherDir/$mdFile.txt" 1 - else - gopherMtime=$(stat -f %c "$gopherDir/$mdFile.txt") - if [ "$fileMtime" -gt "$gopherMtime" ]; then - echo " - $f newer than $gopherDir/$mdFile.txt" - generate_gopher "$f" "$gopherDir/$mdFile.txt" 0 - fi - fi -done - -# handle phlog entries -mkdir -p "$gopherDir/phlog" -sortedEntries=$(find ./phlog -name "*txt" | sort -r) -echo "$sortedEntries" | while read -r f; do - file=$(basename "$f") - fileMtime=$(stat -f %c "$f") - if [ ! -f "$gopherDir/phlog/$file" ] || [ "$force" = "1" ]; then - echo " - $gopherDir/phlog/$file does not exist" - copy_phlog_entry "$f" 1 - else - phlogMtime=$(stat -f %c "$gopherDir/phlog/$file") - if [ "$fileMtime" -gt "$phlogMtime" ]; then - echo " - $f newer than $gopherDir/phlog/$file" - copy_phlog_entry "$f" 0 - fi - fi -done - -# generate html index -if [ -f generate_index_html.flag ] || [ "$force" = "1" ]; then - echo " - generate html index" - generate_html_index "$sortedArticles" - rm generate_index_html.flag -fi - -# generate gophermap -if [ -f generate_gophermap.flag ] || [ "$force" = "1" ]; then - echo " - generate gopher map" - generate_gophermap "$sortedArticles" - rm generate_gophermap.flag -fi - -# generate phlog map -if [ -f generate_phlogmap.flag ] || [ "$force" = "1" ]; then - echo " - generate phlog map" - generate_phlogmap "$sortedEntries" - rm generate_phlogmap.flag -fi diff --git a/post-receive b/post-receive @@ -1,29 +0,0 @@ -#!/bin/sh - -set -eu - -workdir="/home/paco/onna.be" -triggerBranch="production" -repoPath="/var/repos/onna.be.git" -htmlDir="/var/www/htdocs/onna.be" -gopherDir="/var/gopher" - -test -d "$workdir" || mkdir -p "$workdir" - -while read oldrev newrev refname -do - branch=$(git rev-parse --symbolic --abbrev-ref "$refname") - if [ "$branch" = "$triggerBranch" ]; then - cd "$workdir" || exit 1 - unset GIT_DIR - if [ -d .git ]; then - git checkout production - git pull - else - git clone -q "$repoPath" . - fi - ./deploy.sh -d "$htmlDir" -g "$gopherDir" - fi -done - -# vim:set ft=sh diff --git a/src/.ggenignore b/src/.ggenignore @@ -0,0 +1,6 @@ +.ssgignore +.ggenignore +*html +style.css +rss.png +favicon.ico diff --git a/src/.ssgignore b/src/.ssgignore @@ -0,0 +1,4 @@ +gophermap +.ssgignore +.ggenignore +phlog diff --git a/static/44CA735E.asc b/src/44CA735E.asc diff --git a/src/_footer.html b/src/_footer.html @@ -0,0 +1,2 @@ +</body> +</html> diff --git a/src/_header.html b/src/_header.html @@ -0,0 +1,19 @@ +<!DOCTYPE html> +<html> +<head> +<meta charset="utf-8" /> +<meta name="viewport" content="width=device-width,initial-scale=1" /> +<meta name="author" content="paco" /> +<link rel="alternate" type="application/atom+xml" href="/rss.xml"> +<link rel="stylesheet" href="style.css" /> +<title></title> +</head> +<body> +<p> +<a href="/">home</a> / +<a href="https://git.onna.be/">code</a> / +<a href="contact.txt">contact</a> / +<a href="gpgkey.asc">GnuPG Key</a> / +<a href="gpg_keys_transition.txt">Keys transition statement</a> +</p> +<hr/> diff --git a/static/authorized_keys b/src/authorized_keys diff --git a/static/authorized_keys.asc b/src/authorized_keys.asc diff --git a/static/authorized_keys.sig b/src/authorized_keys.sig diff --git a/src/blocking-abusers.md b/src/blocking-abusers.md @@ -0,0 +1,80 @@ +# Blocking abusers on personal servers (OpenBSD PF) +2018-09-07 + +Inspired by Jordan Geoghegan's article about [pf-badhost][1] I wanted to +create my own list based on the "attack attempts" I get on my personal +servers. This was tested on OpenBSD 6.3. + +I just put together a small shell script that parses the httpd(8) logs +and creates 2 files. One to load into a PF table and another one with +entries I'm not sure about and had to be checked manually (either to add +them to the patterns to search for or to discard them as legit). + +It's all really simple. The script is this one: + + + #!/bin/sh + + FILE=$1 + BLOCK=$2 + BAD="" + UNKNOWN="" + + patterns="login.cgi + admin + php + webdav + iframe" + + [ -z "$FILE" ] && echo "Need a log file" && exit 1 + + while IFS= read -r line + do + # ignore first line (rotation) + echo "$line" | grep -q newsyslog && continue + + #gather some info + IP=$(echo "$line" | awk '{print $2}') + REQ=$(echo "$line" | awk -F'"' '{print $2}' | awk '{print $2}') + + # if you're behind a NAT and want to remove your network segment ... + # is not really needed if you just filter on egress, but still. + # echo "$IP" | grep -q "^10\\.42" && continue + + # sort things into unknown and bad folks + if echo "$REQ" | grep -q -e "$patterns" ; then + BAD="${BAD}${IP} + " + else + UNKNOWN="${UNKNOWN}${IP} ($REQ) + " + fi + done < "$FILE" + + echo "$BAD" | sort -uV > /tmp/bad_folks.txt + echo "$UNKNOWN" | sort -uV >> /tmp/to_check.txt + + # and now we clean for duplicates and stuff ... + cat /etc/pf_tables/bad_folks.txt >> /tmp/bad_folks.txt + sort -uV /tmp/bad_folks.txt > /etc/pf_tables/bad_folks.txt + + # and clean + rm /tmp/bad_folks.txt + + if [ "$BLOCK" = "block" ]; then + doas pfctl -t bad_folks -T replace -f /etc/pf_tables/bad_folks.txt + fi + +Just fill the `patterns` variable with one grep pattern per line. + +Of course you'll have to add some rules to `pf.conf`: + + + table <bad_folks> persist file "/etc/pf_tables/bad_folks.txt" + block in quick on egress from <bad_folks> to any + +Remember to add the necessary permissions on `doas.conf` to the user that runs +the script. + +---- +[1]: https://www.geoghegan.ca/pfbadhost.html diff --git a/src/browser-dependency.md b/src/browser-dependency.md @@ -0,0 +1,277 @@ +# Trying to avoid browser dependency. +2019-05-07 + +Web browsers are almost the only GUI programs I use. They are also the most +bloated and vulnerable programs one can have installed on desktop/laptop. + +Those browsers have to handle a lot of external code that comes from the +websites visited. Not only static html (which is already problematic in some +cases) but also JavaScript, which has to be interpreted and run in your machine +with the obvious risk. + +Is not only a matter of security, but also privacy. Almost every website out +there is tracking you in some way or another. Or worst, is using one of the big +companies to track you, which makes their profiling even easier ... + +And then there's the _ups!_ moments like the recent [Firefox bug][1] that +deactivated all the user plugins. The worst part in my opinion is trying to fix +the thing using the _"Studies system"_, which already has a reputation ... + +The other big browser, Chrome is not free of all this stuff. They spy on you +directly without even hiding it. + +Here you can find a series of techniques to use web browsers as little as +possible. + +## Basic browsing + +For basic stuff, like sites that are mostly text as Wikipedia or others, one +can use a text based browser like [lynx][2]. This becomes impossible with sites +that make heavy use of JavaScript or sites that require captcha to login ... In +that case, the only alternative I can think of is use a conventional browser +with plugins like uBlock Origin or Privacy Badger. + +## Bookmarks + +There are some ways of have your bookmarks totally independent from a browser. +I choose to use [shiori][3]. It's a terminal utility that you can use to add, +search, or open bookmarks. It also has a web interface if you prefer that. + +A simple search can be done like this: + + shiori search keyword + +You cal also specify tags in the search with `-t`. Then you can open it in your +default browser with: + + shiori open id + +Take a look at `help`, it's really easy. + +You can also import/export bookmarks in html format as most browsers +understand, so migrating to/from `shiori` is quite easy. + +## Downloads + +Whenever I can, I use [curl][4], `ftp(1)` or [wget][5] from the command line with +direct links. If using a text based browser, then it should have its own way of +dealing with downloads. + +Some sites do not like user that do not use conventional browsers, as those are +more difficult to track (not impossible, just a bit more difficult). Some of +them block requests that don't come from _"regular"_ user agents, so it's +usually a good idea to configure your tools to identify themselves as Mozilla +Firefox or Google Chrome. Most of the times that is enough. + +If using bittorrent to download stuff, the problem is to find a torrent website +that is not completely full of crap and you can just take the magnet links +(because you should be using magnet links). Try to use API calls if your +favourite tracker allows it. + +I usually use [rarbg][6]. You have a lot of alternatives to interact with its +[api][7]. A long time ago I did some Perl module for it called +[Rarbg::torrentapi][8]. Then I use a sort of interactive script to search +torrents on the terminal, it pairs with [transmission][9] to send the magnet +links directly to the torrent client. + + #!/usr/bin/env perl + + use v5.24; + use strict; + use warnings; + use Rarbg::torrentapi; + use Getopt::Long; + no warnings 'experimental'; + + sub usage { + say + "Usage: $0 [--list] [--search <string>] [--categories <category>] [--limit <n>]"; + say "\t--list\t\t\tlists last added torrents sorted by seeds."; + say + "\t--search <string>\tsearches for <string> and returns sorted by seeds"; + say + "\t--category [movies|tv|music|xxxx]\tuses those categories (defaults to movies)"; + say "\t--limit [25|50|100]\tShows 'n' results (defaults to 25)"; + exit 1; + } + + my $tapi = Rarbg::torrentapi->new(); + my $counter = 0; + my $search = ""; + my $list; + my $result; + my $raw_category = ''; + my $category; + my $limit = 25; + + GetOptions( + "search=s" => \$search, + "list" => \$list, + "category=s" => \$raw_category, + "limit=i" => \$limit + ) or usage(); + + given ($raw_category) { + when ( $_ eq 'movies' or $_ eq 'tv' ) { + $category = $raw_category; + } + when ( $_ eq 'music' ) { + $category = '2;23;24;25;26'; + } + default { + $category = 'movies' + } + } + + if ($search) { + $result = $tapi->search( + { sort => 'seeders', + limit => $limit, + category => $category, + search_string => $search + } + ); + } + elsif ($list) { + $result = $tapi->list( + { sort => 'seeders', + limit => $limit, + category => $category + } + ); + } + else { + usage(); + } + + if ( ref($result) eq 'ARRAY' ) { + foreach my $t ( @{$result} ) { + printf( + "%d -> %s (%.2f GB # %d seeds)\n", + $counter, $t->title, $t->size / 1073741824, + $t->seeders + ); + $counter++; + } + } + elsif ( ref($result) eq 'Rarbg::torrentapi::Error' ) { + die "[*] We got an error: $result->{error}"; + } + else { + die "[*] Unexpected Error"; + } + + print "Input selection, separated by spaces. (Ctrl+C to quit) "; + my $selection = <STDIN>; + chomp $selection; + + if ( $selection =~ m/\d{1,2} ?/ ) { + my @selections = split( / /, $selection ); + foreach my $s (@selections) { + say "[*] You selected: " . $result->[$s]->title; + say " [-] sending magnet to transmission:\n" + . $result->[$s]->download; + my $magnet = $result->[$s]->download; + `transmission-remote MYTORRENTHOST --authenv -a $magnet`; + } + } + else { + die "selection is not a number!"; + } + +## RSS feeds + +The best solution I found for this is [newsboat][10]. You can use it directly +(providing a list of feeds to pull from) or connecting it to a supported +external service like [ttrss][11]. I happen to have access to a `ttrss` +installation, so I use that and also have the Android app on my phone. That way +I keep track of what I have read/seen. + +`newsboat` allows you to configure the browser it will use to open links. I +find useful to have a wrapper script as configured browser, so it routes the +different kinds of links to different programs, and defaults to a web browser +if needed. I also use it for other stuff on the command line, is pretty +convenient. + + #!/usr/bin/env bash + + ext="${1##*.}" + videoSites="youtube.com|youtu.be|diode.zone|peertube.social" + videoFiles="mkv mp4 gif webm mpd" + audioFiles="mp3 flac" + imageFiles="png jpg jpeg" + + if echo "$imageFiles" | grep -q -w "$ext"; then + feh -q "$1" & disown + elif echo "$videoFiles" | grep -q -w "$ext"; then + mpv --really-quiet --pause --keep-open "$1" & disown + elif echo "$audioFiles" | grep -q -w "$ext"; then + # I like podcasts and the like to open on a small terminal + urxvtc -geometry 60x6 -e mpv --pause --keep-open "$1" & disown + elif echo "$@" | grep -q -E "$videoSites"; then + mpv --really-quiet --pause "$1" & disown + else + firefox --private-window "$1" > /dev/null 2>&1 & disown + fi + +And then you tell `newsboat` to use it like so: + + browser "/path/to/my/script/linkhandler.sh %u" + +## Images + +You can use [feh][12] to see links to images. It just works. + +It can also be used to set up your background image on simple window managers, +invoked from `.xinitrc` or `.xsession` + +## Videos (and streaming) + +A good alternative to watch videos and streaming on the browser is [mpv][13]. It +has integration with [youtube-dl][14] (which not only "understands" youtube +links, but many many more). With a bit of configuration you won't need the +browser for video any more. Here is my `~/.config/mpv/mpv.conf` + + # sound works better like this on OpenBSD + ao=sndio + # try gpu accelerated video + vo=gpu,xv + # full screen by default + fs=yes + # user agent ... because the web sucks. + user-agent="Mozilla/5.0 (Windows NT 6.1; rv:60.0) Gecko/20100101 Firefox/60.0" + # moarrr cache + cache=yes + cache-default=8192 + # no 4k monitor so limit to best 1080 + ytdl-format=bestvideo[height <= 1080]+bestaudio/best + # do not send that through the HE tunnel (ignore if you do not have this) + ytdl-raw-options=force-ipv4= + +Keep in mind that some streams might not work with mpv under OpenBSD (my OS of +choice). That's because `ffmpeg` does not come with DASH demuxing compiled in +by default. I sent a patch to the port maintainer some time ago. I hope it will +be commited soon. In the mean time contact me if you need that functionality +and I'll send you the patch and instructions. + +## Conclusion + +So those are the programs I use to try to stay away from the browser as much as +possible. If you have other alternatives or suggestions, contact me and I'll +add them here. + +--- +[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1548973 +[2]: https://lynx.invisible-island.net/ +[3]: https://github.com/RadhiFadlillah/shiori +[4]: https://curl.haxx.se/ +[5]: https://www.gnu.org/software/wget/ +[6]: https://rarbg.com/ +[7]: https://torrentapi.org/ +[8]: https://metacpan.org/pod/Rarbg::torrentapi +[9]: https://transmissionbt.com/ +[10]: https://newsboat.org/ +[11]: https://tt-rss.org/ +[12]: https://feh.finalrewind.org/ +[13]: https://mpv.io/ +[14]: https://youtube-dl.org/ diff --git a/src/brymen869s-serial-cable.md b/src/brymen869s-serial-cable.md @@ -0,0 +1,60 @@ +# Brymen 869s Serial cable build. +2018-12-08 + +The Brymen 869s is a fantastic multimeter. Among a lot of other +functionalities it has serial communication to a PC. The problem is +the cable for this is hugely overpriced. Luckily building one is not so +complicated. Besides, some clever folks on the [EEVBlog Forum][1] have +already decoded the protocol the cable uses. + +Well, the usb protocol the cable uses is public, but the protocol used +between the meter and the serial adapter is not. + +This is a infrared communication (so it keeps isolated the pc and the +meter), so some infrared LED and photodiode (or a phototransistor) are +needed. The parts list for all the circuit are small. + + * One micro controller (ATTiny85 in my case, use what you're + comfortable with). + * One infrared diode. + * One current limiting resistor for it. + * (In my case) one NPN BJT, as the micro could not output enough + current for the LED I used. But this is optional if your LED is + directly driven by the micro. + * One photodiode or phototransistor. + * One suitable limiting resistor for that one too. + * A usb to serial adapter if your micro cannot talk usb directly. + +I've attached the [schematic][2] of what I did come up with with the parts +I had lying around at home. + +The [code][3] is just adapted from what user 'jesuscf' did on the EEVBlog +Forum for arduino. I "ported" it to work with AVR C on the ATTiny85. + +The interesting part is how it works. The 'cable' (ATTiny85 driving the +IR LED in this case), sends a 10ms pulse to the meter, it then waits for +the signal from the meter to go high. After that the cable starts +sending a clock signal and the meter starts sending data synced with +that clock. + +One complete "packet" are 20 bytes. Sixteen of them are data and the +last four are fix. The description of each byte can be seen on bm869s.h + +Once we got data, is just a matter of deciding what and how to send it +to the pc via serial. + +I've also designed a small 3D printed case for it, similar to the +original cable attachment, so the circuit can be easily attached to the +meter and the LEDs are well placed, pointing in the right direction and +with almost no interference from other sources. The design is on the +repo. It's a FreeCAD file. I've also uploaded an [STL file][4] in case +somebody wants to use it without installing FreeCAD. + +All and all a small but pretty fun project to do on a weekend. And now I +have data logging on my meter for almost no cost. + +----- +[1]: https://www.eevblog.com/forum/testgear/brymen-ir-connection-protocol-anyone-sniffed-it-yet/ +[2]: https://onna.be/files/brymen_cable_schematic.png +[3]: https://git.onna.be/brymen_bm869s_ir_cable/ +[4]: https://onna.be/files/brymen_cable_attachemnt_v2.stl diff --git a/static/contact.txt b/src/contact.txt diff --git a/static/contact.txt.asc b/src/contact.txt.asc diff --git a/static/contact.txt.sig b/src/contact.txt.sig diff --git a/src/favicon.ico b/src/favicon.ico Binary files differ. diff --git a/static/files/brymen_cable_attachemnt_v2.stl b/src/files/brymen_cable_attachemnt_v2.stl Binary files differ. diff --git a/static/files/brymen_cable_schematic.png b/src/files/brymen_cable_schematic.png Binary files differ. diff --git a/src/files/cetus_config.diff b/src/files/cetus_config.diff @@ -0,0 +1,102 @@ +--- cetus_v6_config Fri Jan 18 12:40:17 2019 ++++ config Fri Jan 18 13:04:03 2019 +@@ -163,41 +163,12 @@ + + ## PID configuration + ## See http://smoothieware.org/temperaturecontrol#pid +-temperature_control.hotend.p_factor 22 #23.0 +-temperature_control.hotend.i_factor 1.047 #1.104 +-temperature_control.hotend.d_factor 115 #120 ++temperature_control.hotend.p_factor 30.7 ++temperature_control.hotend.i_factor 1.477 ++temperature_control.hotend.d_factor 160 + +-temperature_control.hotend.max_pwm 160 # max pwm, 64 is a good value if driving a 12v resistor with 24v. ++temperature_control.hotend.max_pwm 255 + +-####################################### optional use underside port as 2nd extruder +-# second hotend configuration +-temperature_control.hotend2.enable false # Whether to activate this ( "hotend" ) module at all. +-temperature_control.hotend2.thermistor_pin 0.26 # Pin for the thermistor to read +-temperature_control.hotend2.heater_pin 0.4 # Pin that controls the heater, set to nc if a readonly thermistor is being defined +-#temperature_control.hotend2.thermistor EPCOS100K # see http://smoothieware.org/temperaturecontrol#toc5 +-temperature_control.hotend2.beta 3950 # or set the beta value +-temperature_control.hotend2.set_m_code 104 # +-temperature_control.hotend2.set_and_wait_m_code 109 # +-temperature_control.hotend2.designator T1 # +-temperature_control.hotend2.max_temp 300 # Set maximum temperature - Will prevent heating above 300 by default +-temperature_control.hotend2.min_temp 20 # Set minimum temperature - Will prevent heating below if set +- +-# Safety control is enabled by default and can be overidden here, the values show the defaults +-# See http://smoothieware.org/temperaturecontrol#runaway +-temperature_control.hotend2.runaway_heating_timeout 900 # How long it can take to heat up, max is 2040 seconds. +-#temperature_control.hotend2.runaway_cooling_timeout 0 # How long it can take to cool down if temp is set lower, max is 2040 seconds +-temperature_control.hotend2.runaway_range 50 # How far from the set temperature it can wander, max setting is 63°C +- +-# PID configuration +-# See http://smoothieware.org/temperaturecontrol#pid +-#temperature_control.hotend2.p_factor 30 # P ( proportional ) factor +-#temperature_control.hotend2.i_factor 0.3 # I ( integral ) factor +-#temperature_control.hotend2.d_factor 300 # D ( derivative ) factor +- +-##temperature_control.hotend2.max_pwm 64 # max pwm, 64 is a good value if driving a 12v resistor with 24v. +-####################################### +- +- + ###################################### Cetus use the underside port as bed control enable for tinyfab heatbed driver + temperature_control.bed.enable false # Whether to activate this ( "hotend" ) module at all. + temperature_control.bed.thermistor_pin 0.26 # Pin for the thermistor to read +@@ -283,7 +254,7 @@ + endstops_enable true # The endstop module is enabled by default and can be disabled here + #corexy_homing false # Set to true if homing on a hbot or corexy + #alpha_min_endstop 1.25^ # Pin to read min endstop, add a ! to invert if endstop is NO connected to ground +-alpha_max_endstop 1.24^ # Pin to read max endstop, uncomment this and comment the above if using max endstops ++alpha_max_endstop 2.13^ # Pin to read max endstop, uncomment this and comment the above if using max endstops + alpha_homing_direction home_to_max # Or set to home_to_max and set alpha_max and uncomment the alpha_max_endstop + alpha_min 0 # This gets loaded as the current position after homing when home_to_min is set + alpha_max 180 # This gets loaded as the current position after homing when home_to_max is set +@@ -296,7 +267,7 @@ + gamma_max_endstop 1.28^ # Pin to read max endstop, uncomment this and comment the above if using max endstops + gamma_homing_direction home_to_max # Or set to home_to_max and set alpha_max and uncomment the alpha_max_endstop + gamma_min 0 # This gets loaded as the current position after homing when home_to_min is set +-gamma_max 190 # This gets loaded as the current position after homing when home_to_max is set ++gamma_max 180.7 # This gets loaded as the current position after homing when home_to_max is set + + alpha_max_travel 190 # Max travel in mm for alpha/X axis when homing + beta_max_travel 190 # Max travel in mm for beta/Y axis when homing +@@ -339,13 +310,13 @@ + + ## Z-probe + # See http://smoothieware.org/zprobe +-zprobe.enable false # Set to true to enable a zprobe +-zprobe.probe_pin 2.13 #2.13!^ # Pin probe is attached to, if NC remove the ! (2.13 = door check port) ++zprobe.enable true # Set to true to enable a zprobe ++zprobe.probe_pin 1.24!^ #2.13!^ # Pin probe is attached to, if NC remove the ! (2.13 = door check port) + zprobe.slow_feedrate 5 # Mm/sec probe feed rate + #zprobe.debounce_count 100 # Set if noisy + zprobe.fast_feedrate 100 # Move feedrate mm/sec + zprobe.probe_height 10 # How much above bed to start probe +-#gamma_min_endstop nc # Normally 1.28. Change to nc to prevent conflict, ++gamma_min_endstop nc # Normally 1.28. Change to nc to prevent conflict, + + # Levelling strategy + # Example for 3-point levelling strategy, see wiki documentation for other strategies +@@ -358,6 +329,18 @@ + #leveling-strategy.three-point-leveling.probe_offsets 0,0,0 # the probe offsets from nozzle, must be x,y,z, default is no offset + #leveling-strategy.three-point-leveling.save_plane false # set to true to allow the bed plane to be saved with M500 default is false + ++leveling-strategy.rectangular-grid.enable true # The strategy must be enabled in the config, as well as the zprobe module. ++leveling-strategy.rectangular-grid.x_size 140 # size of bed in the X axis ++leveling-strategy.rectangular-grid.y_size 170 # size of bed in the Y axis ++leveling-strategy.rectangular-grid.size 7 # The size of the grid, for example, 7 causes a 7x7 grid with 49 points. ++ # Must be an odd number. ++leveling-strategy.rectangular-grid.do_home true ++leveling-strategy.rectangular-grid.probe_offsets 0,-10,0 # Optional probe offsets from the nozzle or tool head ++leveling-strategy.rectangular-grid.save true # If the saved grid is to be loaded on boot then this must be set to true ++leveling-strategy.rectangular-grid.initial_height 10 # will move to Z10 before the first probe ++#leveling-strategy.rectangular-grid.dampening_start 0.5 # compensation decrease point (optional) ++#leveling-strategy.rectangular-grid.height_limit 1 # no compensation to apply after this point (optional) ++mm_per_line_segment 1 # necessary for cartesians using rectangular-grid + + ## + # Panel See http://smoothieware.org/panel diff --git a/static/files/cetus_limit_switch.tar.gz b/src/files/cetus_limit_switch.tar.gz Binary files differ. diff --git a/static/files/cetus_zprobe_holder.stl b/src/files/cetus_zprobe_holder.stl Binary files differ. diff --git a/static/files/vcvrack_test.mp3 b/src/files/vcvrack_test.mp3 Binary files differ. diff --git a/src/free-cetus.md b/src/free-cetus.md @@ -0,0 +1,208 @@ +# Cetus3D printer mods (free cetus !) +2019-01-16 + +The Cetus is a 3D printer by [Tiertime][1]. +It's small and affordable (although not on the super cheap range of the +Chinese printers). Also the quality of the build and hardware components +is quite good, featuring linear rails and a 32bit cpu. + +The downside to this printer is that the firmware on the printer is not +open source, and it does not work with gcode as the vast majority of the +other printers on the market do. Once you buy it, you're stuck with the +slicer that Tiertime provides which, of course, only works for Mac and +Windows ... and although it is super simple and "it just works", it's +really annoying in some aspects. + +So, there's the reason on trying to fix something that's not broken. + +There's a [company][2] that has developed a drop-in replacement of the +original cpu board, but that runs with an open source firmware +([smoothieware][3]). + +The main goal is to use open source software on all the steps of the +process, from design to print, so I won't have nasty surprises in the +future (when Tiertime discontinues the printer, or stops giving support +for it, or any of the fun stuff companies like to do, so they try to +force you to buy new products) and use the OS that I want, and also a +better control of the print settings for some 3D models that need more +than the basics. + +The model I own is a MKII. This model does not have end stop switches. +The homing is done when the cpu detects that the motors are stuck +because they have reached end of travel. A bit crude, but I guess it +saves cost on production. + +So, the first step for this conversion is to install limit switches. +This is called "downgrade to MKI by Tinyfab". This needs to be done +because the new cpu does not support that kind of brute homing. Also, I +prefer the switch homing, as is less aggressive with the hardware, +specially the motors and some small printed parts + +[Here][4] and [here][5] you can find a tarball with the files needed to print +the adapters for the limit switches. They are the same files provided by +Tinyfab, but renamed so it's clear which ones do you need to use. + +You'll need both X and Y axis pieces and one of the Z axis pieces +depending on the model you have (standard or extended). + +If you plan to use a capacitive bed sensor, print also the piece to fix it to +the hot end carriage. [Here][6] and [here][7] you can find a 3D model I did for +that, as the one Tinyfab provides was broken for me. + +Print this before any disassemble of the machine of course ! + +You can check the installation process on Tinyfab website. For me it was +a little bit different than the pictures they show. So I'll try to +describe it. + +* Remove the X motor (the one for the bed). That will set the belt + loose. Insert the small X axis piece on the aluminium profile, put + together the other part and the limit switch and secure that with + screws to the piece you just inserted on the profile. Put then back + the motor in place. You can push the tension mechanism for the belt + from the other side of the track to make your life easier when putting + back the belt on the pulley. + +* This one is the tricky one. The Y axis. Remove the motor too. In my + case I had to remove the motor mount too, as you have to reach the + screw that secures the belt to the hot end carriage. Be careful, as + this will set the tension belt mechanism loose and the spring is quite + strong. Pull out (but not entirely) the carriage, so the mentioned + screw is visible. Take it out and replace it for the longer piece you + printed. This is the one that will activate the limit switch. Put all + back together carefully. Now remove the small cable routing piece that + is attached to the motor, and replace it with the bigger Y axis piece + you printed. The limit switch goes inside it. + +* The last one, Z, is the easy one. Just take out the first 2 screws on + the vertical linear rail and pull out the whole cap (oh, you should + remove the filament if you have any and the plastic tube). The limit + switch goes inside the new cap. It can be a bit difficult to see, but + there are a couple of holes for screws inside the piece so you can + secure the switch to it. The switch bearing faces up. The pictures on + the website may give you a hint. + +Now it's time to open the main printer case and access the motherboard. + +Remove the current _"limit switches"_, in case of the MKII those are some +extensions to the cables that come from the motors. Connect the new ones +in place and route the cables so they are not in the way and all axis +can move freely. I routed mine below the Z axis motor. + +In case you also want to use the bed capacitive probe, you'll have to +solder a connector to the "case open" slot and put the X axis limit +switch there (and the bed probe where the X limit is supposed to be). +This is needed because the case open slot does not provide the power +needed by the capacitive sensor. Also, some changes will be needed on +the config later. + +Remove the stock cpu and replace it by the tinyfab one. Simplest step in +the whole process. + +Get the last firmware file from Tinyfab website. It comes with an +example config file already. + +Connect the printer via USB to a computer. It will appear as an external +drive. That's the SD card on the printer board. + +At this point, if you just copy the config file as the Tinyfab docs say +and reboot the printer, you're almost good to go. Put there the firmware +and rename it to 'firmware.bin' so it gets upgraded on next boot, just +in case the cpu did not have the last version installed already. + +Set up the `gamma_max`, which is the max travel on the Z axis. I did +this manually with the _"paper"_ method. So connect with a Gcode sender +program like Repetier-Host or UGS. Then: + +* Home all axis with `G28` (be prepared to turn the printer off in case of + failure, one axis going to the other side, ....) +* Set coordinates to absolute with G90 +* Go to 0,0 on XY with `G0 X0 Y0` +* Lower Z until the nozle traps the paper. Take a look at Z position. + That's your new `gamma_max`. + +Now, enjoy your free 3D printing experience ! + +I did some config tweaks though. [Here][8] and [here][9] they are for +reference. + +Basically, I removed the section for the second hotend, as it was +bothering me and I'll never have one on this printer. + +Changed the X axis limit switch pin, as there is now the capacitive bed +sensor, so `alpha_max_endstop` is now `2.13^` + +I also enabled the zprobe, set up the good pin number `1.24!^` and did the +bed level process. It's a bit tricky, but it works in the end (mind that +I use the "Rectangular grid compensation" method as described on +smoothieware [website][10], maybe the easier triangular method is enough) + +* Home all axis with `G28` +* Start the probe process with `G32` +* Save the results and the calibration file with `M500` and `M374` +* Home again and you're good to go. + +This calibration will be read on power up by the printer, so no need to +do it again unless you change something related to the bed plate. + +Some things to take into consideration, I cheated a bit to be able to +perform the process. The way it works is, you define a bed size and an +odd number to be the size of the probing grid, in my case 7 (so 7x7 +points will be probed). You al so need to enter the offset of the nozle +and the probe. The problem is that that offset gets added to the bed +dimensions for probing, so in my case the offset would be +40 for the X +and -10 for the Y, that means that the probing would start at -40 on the +X and will end on 190 on the Y. Maybe for other printers that makes +sense, but the Cetus has its travel limited to the size of the bed. + +So what I end up doing, was set up a bed grid size of 140 on the X by +170 on the Y and setting up only the Y offset. It's not perfect, but is +close enough and it works kind of right. + +Also I did a pid temperature auto test. You can get more info about +this [here][11]. It can easily be done with the command: + + M303 E0 S210 + +`M303` is the actual command, `E0` is the heater (0 as is the first and +only), and `Sxxx` is the target temperature. Use a temperature you're +going to use in real prints. + +At the end you'll get a message like: + + Cycle 4: max: 246.189, min: 227.627, avg separation: 0.418274 + Ku: 34.9838, Pu: 39.85 + Trying: + Kp: 21.0 + Ki: 1.053 + Kd: 105 + PID Autotune Complete! The settings above have been loaded into memory, but not written to your config file. + +So there you have your pid values you can put on the config file. Mine +won't be probably good for you, although default ones may work. + +And finally I modified the max PWM value for the hot end control. The +default was 160 and I could not get the hot end to temperature ... it +fell always short. Maybe 255 is too much and a little lower is ok, I +still have to try that. I hope is not too much and I don't fry +something. + +With all this, the Cetus is now a normal printer you can use in +combination with the open source slicer and gcode sender of your choice. +I personally prefer [Slic3r][12] and [Octoprint][13] (so the printer is not +right next to me). + +----- +[1]: https://www.cetus3d.com/ +[2]: https://www.tinyfab.xyz/ +[3]: http://smoothieware.org/ +[4]: https://onna.be/files/cetus_limit_switch.tar.gz +[5]: gopher://onna.be:70/0/files/cetus_limit_switch.tar.gz +[6]: https://onna.be/files/cetus_zprobe_holder.stl +[7]: gopher://onna.be:70/0/files/cetus_zprobe_holder.stl +[8]: https://onna.be/files/cetus_config.diff +[9]: gopher://onna.be:70/0/files/cetus_config.diff +[10]: http://smoothieware.org/zprobe#probing-for-cartesian-machines +[11]: http://smoothieware.org/temperaturecontrol#pid-autotuning +[12]: https://slic3r.org/ +[13]: https://octoprint.org/ diff --git a/src/gopher.md b/src/gopher.md @@ -0,0 +1,96 @@ +# Gopher ! +2018-08-04 + +It came to my attention that [gopher][1] is still active. And I could not +anticipate how active ! + +I like it's simplicity, and the lack of ads/tracking/otherevils so I +though that I would put the content of this site (for what is worth) +available on port 70 too. + +Here's how, so I don't forget immediately. + +This is tested on OpenBSD 6.3 and 6.4. + +First, install a gopher server. In this case [gophernicus][2] + + $ doas pkg_add gophernicus + +I used inetd(8) to expose gophernicus to the world, adding this line to +/etc/inetd.conf: + + gopher stream tcp nowait _gophernicus /usr/local/libexec/in.gophernicus in.gophernicus -h "onna.be" -nv + +`-h` is hostname, and should be a valid one (the hostname of the +machine). `-nv` is disable virtual hosting, which I don't use. There's +more options in it's help or github, but with `-h` you're good to go. + +By default gophernicus will server content on `/var/gopher`. So once +inetd is (re)started, you can take your gopher client of choice and take +a look. You should see something like + + Welcome to Gophernicus! + _______ __ __ + | __|.-----.-----.| |--.-----.----.-----.|__|.----.--.--.-----. + | | || _ | _ || | -__| _| || || __| | |__ --| + |_______||_____| __||__|__|_____|__| |__|__||__||____|_____|_____| + |__| + + If you can see this, it means that the installation of Gophernicus + on this system was successful. You may now add content to this + directory and replace this page. + + ... + + +That's the default "gophermap". You can start adding content to the +default folder at this time, but modifying the gophermap to look better +and link to some content is better. + +For some instructions on how this gopher protocol works, take a look at +this [readme][3] from gophernicus. + +Mine is the same content served on http. I decided not so long ago to +just write everything in plain text and create index.html/gophermaps as +needed. So simplicity to the max. + + o--o-- Articles + + 0Barcodes, Partkeepr and parts providers(TME) partkeepr_barcodes_and_TME.txt onna.be 70 + 0Password management in the terminal done right. pass_terminal.txt onna.be 70 + +As the readme pointed earlier explains, first line is just text (you can +write or put fancy ASCII banners or whatever). Then the links have this +syntax: + + Xname<TAB>selector<TAB>host<TAB>port + +Where `selector` is the path to the resource and `X` is one of: + + Valid filetypes include: + 0 text file + 1 directory + 3 error message + 5 archive file (zip, tar etc) + 7 search query + 8 telnet session + 9 binary file + g GIF image + h HTML file + i info text + I generic image file (other than GIF) + d document file (ps, pdf, doc etc) + s sound file + ; video file + c calendar file + M MIME file (mbox, emails etc) + +There are a couple more special chars for that first line character. +Take a look at docs. + +So now the terminal lovers can find this site at gopher://onna.be/ + +--- +[1]: https://en.wikipedia.org/wiki/Gopher_(protocol) +[2]: https://github.com/kimholviala/gophernicus +[3]: https://github.com/kimholviala/gophernicus/blob/master/README.Gophermap diff --git a/src/gophermap b/src/gophermap @@ -0,0 +1,42 @@ + __ + /\ \ + ___ ___ ___ __ \ \ \____ __ + / __`\ /' _ `\ /' _ `\ /'__`\ \ \ '__`\ /'__`\ + /\ \L\ \/\ \/\ \/\ \/\ \/\ \L\.\_ __\ \ \L\ \/\ __/ + \ \____/\ \_\ \_\ \_\ \_\ \__/.\_\/\_\\ \_,__/\ \____\ + \/___/ \/_/\/_/\/_/\/_/\/__/\/_/\/_/ \/___/ \/____/ + +o--o-- ---------------------------------------------- gopherhole -- o -- + +Sometimes I write things so I do not forget ... + +o--o-- Random (usually tech) stuff + +0Trying to avoid browser dependency. /browser-dependency.md.txt onna.be 70 +0Self hosted XMPP server (on OpenBSD) /self-hosted-xmpp-server.md.txt onna.be 70 +0Teensy MIDI controller /teensy-midi-controller.md.txt onna.be 70 +0Cetus3D printer mods (free cetus !) /free-cetus.md.txt onna.be 70 +0Brymen 869s Serial cable build. /brymen869s-serial-cable.md.txt onna.be 70 +0Performance improvements on NFS mounts on OpenBSD /nfs-performance-improvements-openbsd.md.txt onna.be 70 +0ZFS RAIDZ disk change /raidz-disk-change.md.txt onna.be 70 +0IPv6 setup when your provider doesn't give a shit. /ipv6-config-he.md.txt onna.be 70 +0Blocking abusers on personal servers (OpenBSD PF) /blocking-abusers.md.txt onna.be 70 +0Gopher ! /gopher.md.txt onna.be 70 +0Barcodes, Partkeepr and parts providers(TME) /partkeepr-barcodes-and-TME.md.txt onna.be 70 +0Password management in the terminal done right. /pass-terminal.md.txt onna.be 70 + + +o--o-- Ramblings + +1Phlog /phlog onna.be 70 + +o--o-- More Info + +hCode URL:https://git.onna.be/ +0Contact /contact.txt onna.be 70 +0GnuPG key /gpgkey.asc onna.be 70 +0GnuPG Keys transition statement /gpg_keys_transition.txt onna.be 70 + +o- o -- -------------------------------------------------------- -- o -- +Last updated: Tue May 7 17:23:25 UTC 2019 +o- o -- -------------------------------------------------------- -- o -- diff --git a/static/gpg_keys_transition.txt b/src/gpg_keys_transition.txt diff --git a/static/gpgkey.asc b/src/gpgkey.asc diff --git a/src/index.html b/src/index.html @@ -0,0 +1,18 @@ +<ul> +<li><a href="browser-dependency.html" title="2019-05-07">Trying to avoid browser dependency.</a></li> +<li><a href="self-hosted-xmpp-server.html" title="2019-04-25">Self hosted XMPP server (on OpenBSD)</a></li> +<li><a href="teensy-midi-controller.html" title="2019-03-16">Teensy MIDI controller</a></li> +<li><a href="free-cetus.html" title="2019-01-16">Cetus3D printer mods (free cetus !)</a></li> +<li><a href="brymen869s-serial-cable.html" title="2018-12-08">Brymen 869s Serial cable build.</a></li> +<li><a href="nfs-performance-improvements-openbsd.html" title="2018-11-18">Performance improvements on NFS mounts on OpenBSD</a></li> +<li><a href="raidz-disk-change.html" title="2018-11-13">ZFS RAIDZ disk change</a></li> +<li><a href="ipv6-config-he.html" title="2018-11-09">IPv6 setup when your provider doesn't give a shit.</a></li> +<li><a href="blocking-abusers.html" title="2018-09-07">Blocking abusers on personal servers (OpenBSD PF)</a></li> +<li><a href="gopher.html" title="2018-08-04">Gopher !</a></li> +<li><a href="partkeepr-barcodes-and-TME.html" title="2018-03-08">Barcodes, Partkeepr and parts providers(TME)</a></li> +<li><a href="pass-terminal.html" title="2017-07-16">Password management in the terminal done right.</a></li> +</ul> + +<hr/> + +<p><em>Subscribe via: </em><a href="/rss.xml"><img src="/rss.png" /></a></p> diff --git a/src/ipv6-config-he.md b/src/ipv6-config-he.md @@ -0,0 +1,160 @@ +# IPv6 setup when your provider doesn't give a shit. +2018-11-09 + +This is a small guide to set up IPv6 via [HE][1] tunnel on a mostly +"unixy" environment. + +I've been thinking to play with the new IP version for a while, but +never really get into it until a couple of months ago. + +Sadly most internet providers out there (at least the ones serving +residential buildings) don't give a shit about IPv4 exhaustion or IPv6 +implementation. My provider is one of those. And I could not find in my +area one that provides native IPv6. + +There are other options. The one that came to mind (I've read about it +some time ago) was using [Tunnelbroker][2]. + +That's a 6-in-4 tunnel operated by Hurricane Electric. There are more +companies/projects offering this, here's a [list][3]. + +The process with HE is pretty simple. First one has to register on their +website and then create a tunnel. +This process involves choosing a endpoint server to tunnel your v6 +traffic. Choose one that's "close" to you in internet terms (that +basically means few hops, low latency. `traceroute(8)` and `ping(8)` are +your friends). + +You'll be then assigned a `/64`. Two really, one is for the tunnel itself. +But I won't be using them really (well, just for the tunnel). More on +that later + +On their website they have lots of example configurations. Just choose +your poison and they will provide basic instructions on how to set it +up. + +I wanted to set up this for my entire home/office network. I have a +small fanless OpenBSD machine acting as a router, so the instructions +are super simple: + + ifconfig gif0 tunnel 1.2.3.4 216.66.84.42 + ifconfig gif0 inet6 alias 2001:470:aaa:aaa::2 2001:470:aaa:aaa::1 prefixlen 128 + route -n add -inet6 default 2001:470:aaa:aaa::1 + +With just this, my router has IPv6 connection to the world ! +In this example `1.2.3.4` is my real IPv4 and `2001:470:aaa:aaa/64` is the +range assigned for the tunnel. As said earlier they assign another `/64` +so you can use it on your internal network. + +But, they also offer `/48` just in case you want to create different +subnets and do proper IPv6 auto configuration. You can ask for it once +you complete the registration and successfully establish the tunnel. + +It's still shocking to me that they deliver that prefix ... that means +they just route to you 65536 (+2) /64s ... nuts ! + +Anyway, the goal then is having the tunnel set up permanently, assign a +`/64` to every internal vlan and enable router advertisement for those +too. + +On my OpenBSD machine goes like this: + +Create `/etc/hostname.gif0` (the tunnel interface): + + tunnel 1.2.3.4 216.66.84.42 + !ifconfig gif0 inet6 alias 2001:470:aaa:aaa::2 2001:470:aaa:aaa::1 prefixlen 128 + !route -n add -inet6 default 2001:470:aaa:aaa::1 + +Add IPv6 config for the vlans. Here is the full config of one of mine, +at `/etc/hostname.vlan10` + + inet 10.42.10.1 255.255.255.0 NONE vnetid 10 parent em1 description "cable" up + inet6 2001:470:bbb:cab::1 64 + group internal + +Note that I'm using now part of the `/48` +I'll configure a `/64` for every other vlan in my net. + +Now we'll use `rad(8)` so all the devices on the net have IPv6 +connectivity too. +Here's part of my `/etc/rad.conf` Have a look at `rad.conf(5)` for more info. + + interface vlan10 { + prefix 2001:470:bbb:cab::/64 + dns { + nameserver 2001:470:bbb:cab::1 + search home.my.domain + } + } + +That's nice because we can set up `AAAA` records on a real domain, and HE +provides reverse DNS too ! + +Remember to enable IPv6 forwarding in your router. On OpenBSD is done +via `sysctl(8)/sysctl.conf(5)` + + net.inet6.ip6.forwarding=1 + +Also, check your pf(4) configuration. Most likely you'll need to adjust +it. + +At this point most of the devices in your network will be negotiating +IPv6 auto configuration. I found out that Android and iOS phones do that +automatically, and prefer v6 if present. All linux boxes using `dhcpcd(8)` +will work automatically too. +On Macs I found out that some were configured to take v6 config if +possible and others have it disabled, so just "switch it on" and you're +good to go. + +I have a couple of machines that act like servers, so I needed to set up +ip configuration manually there. Check your OS documentation on any +case. + +My main workstation runs OpenBSD too, so that was simple to set up. +On my `/etc/hostname.em0` + + dhcp + inet6 autoconf + +Also, tell the system resolver to prefer v6 over v4 if you want. On +`/etc/resolv.conf.tail` + + nameserver 2001:470:bbb:cab::1 + lookup file bind + family inet6 inet4 + +And that's it ! It was easier than expected ! + +A couple of caveats, though. + +Network latency could be a bit higher, depending on how packets get +routed to your tunnel server, etc. In my case, oddly enough, most times +latency is better through the tunnel ... which does not speak so well +about my internet provider right ? + +Also, speed may be an issue depending on your current connection. In +theory there's no speed limit on the tunnel. I have 200/200 Mbps here, +and I get about 65/65 Mbps through the tunnel easily. Which is more than +ok for my tests. But it varies in time. I guess they could have load +issues at some point. + +Besides, Netflix and other streaming services are not happy with you +using those ip ranges. You'll see the same error you get when you try to +use most vpns on the market ... So basically you may have problems with +any service that controls you to the extreme and cares about where you +connect from. The lesson here, don't use those services :-P + +And that's all folks ! +With some kind-of-simple steps one can have billions of public routable +ip addresses to play with at home/office/whatever for free. + +Another cool thing. HE has this [IPv6 Certification][4]. Is not that hard +if you take some time to do it and you'll learn a lot in the process. +Besides, they will send you a super nerd t-shirt when you complete all +levels ;-) + +----- +[1]: http://he.net/ +[2]: https://tunnelbroker.net +[3]: https://en.wikipedia.org/wiki/List_of_IPv6_tunnel_brokers +[4]: https://ipv6.he.net/certification/ diff --git a/src/long-wireless-links-and-monitoring.md b/src/long-wireless-links-and-monitoring.md @@ -0,0 +1,337 @@ +# Long Wireless links and monitoring. +2019-07-19 + +## Intro + +Some time ago I built 2 [P-t-P][1] links between some family members' buildings. + +Thing is that my brother and my sister live in an area with no coverage from +traditional ISPs, but that is quite close (5.5km on a straight line, with no +obstacles) to my parent's which have good coverage (even FTTH) and plenty of +providers to choose from. + +This project has grown _organically_ so to speak, and the requisites kept +changing. + +That, and my lack of experience on the subject make all this far from an +optimal solution. + +In the end it has been working for almost 3 years now. This is an attempt to +document all the infrastructure and the bits and pieces used so I do not forget +about it and maybe it can be of use to somebody else. + +## First steps and research + +As I said, I knew nothing about this before tackling the project. I have some +solid knowledge about networking, but I knew little about long (for me) +wireless links, antennas, propagation and a bunch of other stuff I did not know +existed, so I had to do some research. + +If you want to do something like this, is better to plan ahead. See what the +requisites are and start digging. + +Some things to take into consideration are: + +* Budget. This is an important one in this scenario, as this is for personal + use only. +* Distance between the endpoints of the link. Modern hardware (more on my + choice later), can easily cover 10km or maybe more, but read the + manufacturer's datasheet and look for output power, antenna gain and + sensitivity. And always take their numbers with a grain of salt, as they + are usually tested on ideal conditions you won't encounter. You'll find + later a way to calculate the ideal numbers to have an estimate. +* Obstacles. There has to be perfect clear vision between endpoints. Wireless + communications, especially WiFi either on 2.4GHz or 5GHz, are very + sensitive to obstacles. Even partial cover can have a big impact on link + quality. And clear vision does not mean _"I can see a single point in the + distance"_, there's this thing called [Fresnel zone][2], under some + atmospheric conditions or spectrum saturation it will give you a lot of + trouble. +* Materials. Don't be cheap. This will have to resists the outdoor conditions + for as long as possible. +* Neighbours and regulations. There's the legal part (RF regulations in your + country and things like that) and the _"social"_ part, in this case my + family does not live in detached houses but on apartments, so that has to + be taken into consideration if there are any rules about this. +* Infrastructure. And by that I mean all the necessary to be able to install + the antennas, route the cables, install connectors, etc. I'm not only + talking about tools, but also access to the best spots to put the antennas, + etc. +* Antenna location. As a rule of thumb, the higher the better. But this + depends a lot on your particular situation. It deserves some thought. +* Spectrum saturation. Wifi is ubiquitous now. That may be a challenge for + any installation specially on urban areas. Ideally, you should check how + _crowded_ the spectrum is, but this is usually pretty difficult for + amateurs without special equipment. Some antennas have a built in spectrum + analyser, but it may perform badly. + +## Materials + +This is a list of materials I choose and why I choose them. It is short, as it +is really an easy installation. + +### Antennas + +I ended up using [Ubiquity PowerBeams][2] to create the 2 links. Four in +total, 2 for each link. + +I was looking for some reputable manufacturer trying to avoid problems in the +future. Also, I wanted something as simple as possible. This kind of antennas +have the _"emitter/receiver"_ and the antenna all in the same device. So no +special connectors to be crimped, virtually no losses on cables, just an easy +[PoE][4] setup from the house to the rooftop. + +Also, this antenna has an easy to setup web interface _and_ an SSH server that +leaves you in a busybox with some proprietary commands that are pretty handy +for automation and data collection. + +There are newer models now and other manufacturers. Do your research, read on +forums and all the usual stuff. I can say those work for this setup with minor +issues. + +If you know something about this subject you may be wondering why I did not use +something with a wider angle on the _"access point"_ side and use just 3 +antennas instead of 4. Truth is, I tried, but I had some problems with the 2nd +link giving poor performance. Not being an expert on this I can only guess +that the partial obstruction on the LOS (line of sight) path for the second +link was the cause of the poor performance, specially on bad weather days (WiFi +is pretty sensitive to heavy rain) and episodes of spectrum saturation. + +Creating a separate link with a dedicated pair of antennas improved the +situation a lot. + +### Cables + +As the antennas only need a network connection, we only need Ethernet cable. +Be sure that is CAT5e or better. + +Always use cable rated for outdoor use. Regular network cable will not last +long exposed to rain and the sun's UV. I went for [this one][5] because it was +available at the time on Amazon. + +### Connectors + +Don't go extra cheap on this, but anything with reasonable quality will do +here. The antennas are built in a way that the connectors are never exposed, +so this part is not that critical. + +### Antenna pole and other hardware + +I cannot say much about this. What to buy here depends a lot on your +particular setup. Remember that the higher the better for the antennas, and +remember wind is a thing ... you do not want it to fly away like a plastic bag. + +## Build steps + +This is a list of the build steps I took. I started checking the list +mentioned on the [First steps](#first-steps-and-research) section. +Specifically the location of the antennas and the clear line of sight. + +I have to admit that I did a sloppy job on the second link, because I did not +know about the [Fresnel zone][2] back then, but there's some things you can do +to mitigate is effects. + +### Calculate signal strength + +There's a simple way to calculate the signal strength you should see on the +other side of the link (on ideal conditions). This can be taken as a reference +to see if the setup is viable and what conditions and speed negotiation you can +expect between the 2 endpoints of the link. + +The simplified formula to calculate the signal is: + +``` +emitterPower + emitterGain - signalLoss + receiverGain +``` + +I say this is the simplified formula, because it does not take into account +loses on cables and connectors, that's because I choose to use a _"all in one +packet"_ type of antenna, so that makes no sense. This is a huge advantage for +a beginner. Also, because I only take into account the free space loss and not +any other kinds of loss, that would be a lot more difficult to calculate. That +was sufficient for me anyway, as the conditions of line of sight are pretty +good. + +To calculate signal loss, this is the formula: + +``` +loss = 20*log((4*π*d)/λ) +``` + +Being `d` the distance between the 2 endpoints in meters and `λ` the +wavelength, also in meters. If you do not remember how to calculate the +wavelength from the frequency is just: + +``` +λ = C/f +``` + +Being `C` the speed of light in meters per second and `f` the frequency in +Hertz. + +So, as an example, let's say I choose channel `137` which is `5685 MHz`, and +the 2 endpoints are 5.2km apart. That gives us a signal loss of `121.85 dB`. + +According to the antenna datasheet the transmission power is `5 dBm`, the gain +of the antenna is `25 dBi` (that's on average I guess). So putting all that +together I should get on the other end `-66.86 dBm`. This works both ways in +this case, so now we have to check sensitivity. Again according to the +datasheet, there's no problem in any modulation negotiation with this kind of +signal strength (in theory, so to be on the safe side add at least `-3 dB` to +your results). + +### Physical setup and alignment + +With the theory calculations out of the way, knowing that is possible, the fun +part starts, we have to get on the roof now and install the antennas. + +Of course I won't be saying much about this, as this is different for every +single installation. Suffice to say, I had a _"pretty fun time"_ up on ladders +and climbing to places not meant to be climbed ... + +With the antenna installed, before attaching it securely to the pole, it has to +be aligned the right way. + +On the datasheet you'll find radiation plots for your model. The principle is +simple, those are 2D representations of the radiation lobes of the antenna, and +the loss referred to the total gain. So basically you want to point them to +one another as perfectly as possible, specially for parabolic antennas, which +have a very narrow beam. + +Those radiation plots confused me at first as, in case of the PowerBeam there +are 4 of them "Vertical Azimuth", "Vertical Elevation", "Horizontal Azimuth" and +"Horizontal Elevation". This did not make any sense for me in the beginning, +as the azimuth is an horizontal angle and elevation is a vertical one. It +drove me nuts. It turns out it refers to both polarisations of the signal that +those devices create ... Once you understand that is easy, they are just the +same measurement but times 2, one for each polarisation. + +Once you know how many angles you have before starting to loose signal, and +with a bit of the good old trigonometry, you know your margin of error when +pointing the antennas to each other. + +I did this standing behind the antenna and looking as if my line of sight was +the beam. With some fiddling, that should be enough for the horizontal +alignment. For the vertical one, it's easier, because the error margin is +pretty big compared to the distance to the ground, even if you're on a tall +building (again, trigonometry, that angle at 5km is some meters ...). Anyway +with the help of some online tool you can calculate that easily to make it as +precise as possible (search for "antenna downtilt calculator" on your favourite +search engine). + +### Network diagram and configuration + +With the antennas installed, it's time for some configuration. + +This is a basic diagram of the network setup: + +``` + 192.168.1.6/24 + +--------+ + | Bro. | + 192.168.1.2/24 192.168.1.4/24 | Router | + +---------+ +----------+ +--------+ + | Antenna | | Antenna | / 192.168.10.1/24 + ----| AP1 |+++++++++| ST1 |--- + 192.168.1.1/24 ---/ +---------+ +----------+ + +---------+ ++---------+ -| ISP | +|Internet |-/ | Router | ++---------+ +---------+ + | --\ +---------+ +-----------+ + \ --\ | Antenna | | Antenna | + \ --| AP2 |+++++++++| ST2 |-\ + | +---------+ +-----------+ -\ 192.168.1.7/24 + \ 192.168.1.3/24 192.168.1.5/24 +---------+ + +------------+ | Sis. | + | Rpi | | Router | + | Monitoring | +---------+ + +------------+ 192.168.10.1/24 + 192.168.1.10/24 +``` + +All are cable connections but the `++++` ones, which are the 5km links. + +On the routers/APs at the end of the chain I used the same network segment for +both, as hey will be isolated and do NAT. I did this because I have little +control over the ISP router. It is _"reset to defaults"_ from time to time and +that caused me problems before. So setting static routes would be a pain to +maintain. That produces double NAT on my siblings', but that's a small price +to pay for having a stable setup. + +Yes, I know that's a shitty thing to do for an ISP (they break your dhcp +reservations and port forwarding), but most of the ISPs where I live are the +biggest idiots and do the dumbest stuff you can imagine, so that's not even +something for them. + +The PowerBeams are configurable via a web interface that is pretty intuitive. +They can also be configured via an SSH access and editing a text file + some +commands. + +Some things I did: + +* enable WDS (transparent bridge mode), so I see the MAC addresses of all the + chain from my monitoring station. That helps on debugging if something + network goes wrong. +* I enabled SNMP for monitoring, SSH server for access (with public keys) and + NTP so the antennas have the right time (good for logs). +* All 4 antennas are set up on bridge mode. +* The ones connected to the ISP router are set up as "Access Point" and the + other 2 as "Stations" +* The antenna startup wizard asks you for country location. That's because + they apply the necessary regulation restrictions automatically. Do not + cheat here, you can have problems with your local authorities. Besides, if + you do not have good signal within the power output regulations chances are + you're doing something wrong or the conditions of line of sight, etc. are + not really good, so it won't matter and you'll be breaking the law for + nothing (and probably causing problems to other antennas and + installations). + +If you prefer the command line to configure the antennas, log into them via SSH +and edit the file `/tmp/system.cfg`. Then save to `NVRAM` with the command +`cfgmtd -w`. Then reset with `/usr/etc/rc.d/rc.softrestart force`. + +I do not recommend that method at the beginning, until you get familiar with +all the options and configurations possible. You can make a pretty big mess. + +As I said earlier, those antennas have a sort of spectrum analyser you can use +to determine which channel is less busy. It uses some java applet (yes, I know +...) and it has been broken in 2 occasions on some firmware updates. But it +can be of assistance if your spectrum is really busy. + + +### Performance tests + +There are 2 ways to easily test the throughput of the links. The web interface +has a "speed test" built in. You have to put the credentials of the other end +and it can test TX, RX or both. + +The other way (that I like the most) is `iperf(1)`. The antennas have installed +a basic implementation of that tool, so log into the antenna on the other end, +and use `iperf(1)` either as server or client to test both sides of the +communication. + +Play a bit with the channel width. More channel width allows for faster +transfer rates, but a narrow channel increases stability. + +I ended up using `20 MHz` for one of the links and `10 MHz` for the other. +That last one is the one with less than ideal LOS situation. In the end +reducing the channel width and choosing the least busy channel did the trick +and I could get a stable link. + +In the end for the first link I get around `32Mbps` symmetrical. The second +link is a lot more variable depending on the conditions and the interferences +from other stations. I get up to `17Mbps` symmetrical, and is usually more +than `12Mbps`, but on worst case scenario it can get as low as `6Mbps`. Which +is still enough to watch online videos at `1080p` with today's compressions and +is more than enough to do any kind of browsing, email and whatever ... so +I guess is enough. + +### Monitoring + +---- +[1]: https://en.wikipedia.org/wiki/Point-to-point_(telecommunications) +[2]: https://en.wikipedia.org/wiki/Fresnel_zone +[3]: https://www.ui.com/airmax/powerbeam/ +[4]: https://en.wikipedia.org/wiki/Power_over_Ethernet +[5]: https://www.konigelectronic.com/computer/networking/network-cable-reel-cat5e-futp-100-m-black-solid-55896639 diff --git a/src/nfs-performance-improvements-openbsd.md b/src/nfs-performance-improvements-openbsd.md @@ -0,0 +1,43 @@ +# Performance improvements on NFS mounts on OpenBSD +2018-11-18 + +Those are simple notes on how to increase performance (read basically) +on my OpenBSD desktop again my NAS at home. + +The NAS exports a set of folders via various protocols. AFP for the +Macs, NFS for OpenBSD and maybe Linux and Samba for everything else +(basically one Ubuntu I use as media center). + +It runs FreeBSD, and the performance is generally good on all protocols, +limited more or less by the speed of the link 1Gbps but OpenBSD was +reporting some low values, in the order of 390Mbps read and 60 Mbps +write. + +A quick look at the OpenBSD list archives gives me a nice [thread][1] that +explains a lot. + +After some playing around, I applied the following options to the NFS +mount points: + + -T/-U To force TCP or UDP respectively, see below + -3 To force NFSv3 (this is unnecessary as is the default) + -a 4 readahead value set to the max. See mount_nfs(8) + -r 32768 readsize. Again see mount_nfs(8) + -w 32768 writesize. same thing. + noatime I set this up always on network resources. + +Oddly enough, I get more stable results (specially on writes) using TCP +instead of UDP ... + +On TCP that read speed is almost saturating the link, ad 890Mbps and +write speed is way better (enough for me anyway) at 410Mbps + +On UDP read speed is even better around 905Mbps but write speed is poor +and inconsistent at about 128Mbps + +So in the end I end up using TCP. Maybe I'll take a closer look in the +future to see if I can improve write a little bit, but it's OK for me at +this stage. + +----- +[1]: https://marc.info/?l=openbsd-misc&m=146130062830832&w=2 diff --git a/src/partkeepr-barcodes-and-TME.md b/src/partkeepr-barcodes-and-TME.md @@ -0,0 +1,73 @@ +# Barcodes, Partkeepr and parts providers(TME) +2018-03-08 + +Electronic parts are small ... and they get smaller and smaller when you +go down the rabbit hole of SMD components. They are also really difficult +to organize and catalogue. There are useful tools like [Partkeepr][1] to +help you keep things tidy and, most importantly, don't buy things twice +because you can't find them or you don't remember where the hell they +are (or even don't remember that you have them). + +The only drawback to that is that you have to manually insert all the +parts that you buy ... which is tedious. + +I basically get my parts for 4 places: + +* The _slow boat from China_, when piece is important and time is not. +* Ebay, basically same thing, although sometimes there are sellers in + Europe, which is nice ! +* [TME][2], a polish distributor with fairly good prices and good catalogue + that I tend to use when I need to be sure what I'm buying. +* And [Farnell/Element14][3], when I need something that I cannot find + anywhere else ... + +It turns out that the last 2 have good APIs to query their catalogue. And +specifically TME adds a little iQR code to all their packages with some +info. + +With any old webcam you can find, and [zbar][4], you can extract the info +on that iQR code easily, and dump it to `stdout`. It looks something +like this (this is a little 12V fan): + + QTY:1 PN:HA50151V4 MFR:SUNON MPN:HA50151V4-000U-999 PO:xxxxxx/x https://www.tme.eu/details/HA50151V4 + + where: + + FIELD NAME Desc + 0 QTY Quantity + 1 PN Part Number + 2 MFR Manufacturer + 3 MPN Manufacturer part number + 4 PO Order Number (at TME) + 5 Url of the product at vendor(TME) + + +That's easy to parse, and contact TME's API for more info. + +I've put together a little python3 script that takes that from `stdin` +and makes all the necessary calls (to TME and then to Partkeepr), so I +don't have to enter my TME orders by hand anymore. You can find it +[here][5] + +You'll need a token and secret from the distributor. So go to their +developer's [page][6] and sing in. + +It downloads the datasheets too (if they have any) and uploads them to +Partkeepr. If the item is already in the db, it just increments the +stock. + +On the git page you can find more info, but it's really easy to use, +just pipe the output of zbar to the script like this: + + zbarcam --raw /dev/video0 | ./parteye.py + +If I order something from Farnell I'll check if they do something +similar, so I can adapt the script. + +----- +[1]: https://www.partkeepr.org/ +[2]: https://www.tme.eu/ +[3]: http://farnell.com +[4]: http://zbar.sourceforge.net +[5]: https://git.onna.be/parteye/ +[6]: https://developers.tme.eu diff --git a/src/pass-terminal.md b/src/pass-terminal.md @@ -0,0 +1,51 @@ +# Password management in the terminal done right. +2017-07-16 + +_Update_: Some time ago I wrote a little more detailed intro to `pass` on the +[tilde.institute wiki][2] + +I spend most of my time in front a computer in the terminal ... I'm used +to it, and I like it a lot. There's nothing (well, almost nothing) a +terminal app or a combination of apps can't do (way better some times +that its graphical counterparts). + +One of those apps that's particularly useful is [pass][1]. A password +manager for the terminal. + +Is quite simple. It creates a hierarchy of folders and files in +`$PASSWORD_STORE_DIR` (`~/.password-store` by default) and encrypts them with +your GPG key. + +It can copy the recovered passwords to the clipboard, has `bash` and +`zsh` completion. Can generate random passwords for you and more ... + +You can also create multi-line _stores_ with extra information, but just +the first line will be copied to the clipboard when you use `-c`. + +They have a great web page explaining all that, and a really good man +page, so there's no excuse to have ugly methods for managing your +passwords ... or no methods at all ! + +The things I use the most: + + pass -c site/foo.com/username + +This one gets the password for `username@foo.com` and puts it on your +clipboard. + + pass generate -c email/me@foo.com + +This one generates a random password, stores it on `email/me@foo.com` +and copies it to the clipboard. Pretty useful when you're singing in to +a new service. + + pass edit foo/bar/baz + +This one edits one of your entries. Mind that generate won't ask for +password, as you're encrypting to your GPG public key, but edit or show +will. It's a good idea to have GPG agent setup, so you can control +how/when passwords are requested. + +----- +[1]: https://www.passwordstore.org/ +[2]: https://wiki.tilde.institute/w/pass diff --git a/phlog/20181113-1342_entry.txt b/src/phlog/20181113-1342_entry.txt diff --git a/phlog/20181113-1844_entry.txt b/src/phlog/20181113-1844_entry.txt diff --git a/phlog/20181115-1906_entry.txt b/src/phlog/20181115-1906_entry.txt diff --git a/phlog/20181116-2245_entry.txt b/src/phlog/20181116-2245_entry.txt diff --git a/phlog/20181117-1934_entry.txt b/src/phlog/20181117-1934_entry.txt diff --git a/phlog/20181118-2212_entry.txt b/src/phlog/20181118-2212_entry.txt diff --git a/phlog/20181123-1914_entry.txt b/src/phlog/20181123-1914_entry.txt diff --git a/phlog/20190107-1400_entry.txt b/src/phlog/20190107-1400_entry.txt diff --git a/phlog/20190115-1519_entry.txt b/src/phlog/20190115-1519_entry.txt diff --git a/phlog/20190214-0808_entry.txt b/src/phlog/20190214-0808_entry.txt diff --git a/phlog/20190330-2151_entry.txt b/src/phlog/20190330-2151_entry.txt diff --git a/phlog/20190402-0824_entry.txt b/src/phlog/20190402-0824_entry.txt diff --git a/phlog/20190414-1728_entry.txt b/src/phlog/20190414-1728_entry.txt diff --git a/phlog/20190424-1955_entry.txt b/src/phlog/20190424-1955_entry.txt diff --git a/phlog/20190507-1931_entry.txt b/src/phlog/20190507-1931_entry.txt diff --git a/phlog/20190706-1212_entry.txt b/src/phlog/20190706-1212_entry.txt diff --git a/src/raidz-disk-change.md b/src/raidz-disk-change.md @@ -0,0 +1,84 @@ +# ZFS RAIDZ disk change +2018-11-13 + +Here are some notes in order to change a failing disk on a RAIDZ pool. +This has been tested on FreeBSD 11.2. It may work with other versions, +but check `gpart(8)`, `zpool(8)` and the handbook to be sure. + +My NAS runs FreeBSD 11.2 with zroot, 4x3TB disks in raidz1. +Some days ago 1 of those disks started to report quite a few _smart_ +errors. ZFS itself did not report any errors, but I prefer to change the +disk while it still works. It's probably faster (copy over re-build) +and safer, as one does not face the possibility of a failing disk while +rebuilding the RAID. + +In this particular case `ada2` was failing, and ada4 was the new disk. +This will change once the failing disk is removed, but I don't care as I +use gtp labels. + +I don't like GPT GUID labels nor DiskID labels (although I see the point +on this latter ones when you have a bunch of disks ...). So, I have this +on `/boot/loader.conf` + + kern.geom.label.gptid.enable="0" + kern.geom.label.disk_ident.enable="0" + +First thing is to create thg GPT partition table: + + gpart create -s GPT ada4 + +And replicate the same partition scheme on the new disk (in my +particular case replacement disk and replaced disk are the same model): + + gpart backup ada2 | gpart restore -F ada4 + +This only replicates the partition scheme, but not the labels. So that +has to be done manually: + + gpart modify -i 3 -l zfs4 ada4 + gpart modify -i 2 -l swap4 ada4 + gpart modify -i 1 -l gptboot4 ada4 + +As you can see on my schema I have a boot partition on each disk, a swap +partition an another partition which is part of the zpool. + +At this time, we're ready to replace the disk: + + zpool replace zroot gpt/zfs2 gpt/zfs4 + +This can take a lot of time. It all depends on your hardware. In my case +it took over 10h. + +Is a good idea to setup now the bootloader in place on the new disk: + + gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada4 + +Once finished everything is back to normal: + + pool: zroot + state: ONLINE + scan: resilvered 2.15T in 10h23m with 0 errors on Tue Nov 13 04:31:35 2018 + config: + + NAME STATE READ WRITE CKSUM + zroot ONLINE 0 0 0 + raidz1-0 ONLINE 0 0 0 + gpt/zfs0 ONLINE 0 0 0 + gpt/zfs1 ONLINE 0 0 0 + gpt/zfs4 ONLINE 0 0 0 + gpt/zfs3 ONLINE 0 0 0 + + errors: No known data errors + +As a bonus, those commends can help a lot getting information about the +disks, partitions and status: + + zpool status + gpart show + gpart backup <provider> + camcontrol devlist + +Take a look at the respective man pages before executing anything on +your machine ! + +----- diff --git a/src/rss.png b/src/rss.png Binary files differ. diff --git a/src/self-hosted-xmpp-server.md b/src/self-hosted-xmpp-server.md @@ -0,0 +1,253 @@ +# Self hosted XMPP server (on OpenBSD) +2019-04-25 + +Tested on OpenBSD 6.5 (prosody version 0.11.2) + +## Intro + +Self-hosting an instant messaging service is quite simple. This guide shows how +to do it using OpenBSD as a base system and XMPP as the messaging protocol. + +The end result is an End-to-End encrypted chat system for 1:1 or multi-user +conversations. + +The software used for the server is [prosody][1], and it's all based on +[this guide][2]. + +For the clients, I've tried [Gajim][3] for the desktop (works for Windows, +Linux and *BSD), [Conversations][4] on the phone (Android) and [profanity][5] +on the terminal (works almost everywhere). There's a client for iOS called +[ChatSecure][8], but I have not tried it. + +## Rationale + +I used to host my messaging services back in the day. People stopped using this +for some reason, and then came all the Whatsapp and co. So all that was +forgotten. + +Although I never used whatsapp, on recent times I've been testing some instant +messaging systems, but none of them were good enough. In the end, all rely on +central systems, often owned by companies that have to make money from +somwhere. Most of the times is you (one way or another) even if they say the +service is free. + +I wanted something simple, client independent, secure (well, as secure as +possible ...), easy to use from the client point of view and easy to manage +from the server part. My goal is to replace things like Signal that I use with +my family and friends. + +XMPP is federated, just like email is. And with recent extensions like easy to +use End-to-End encryption and http file sharing it's a viable solution for +resilient and secure instant messaging system, that does not spy on you (no +more than encrypted email for instance). + +For now is not a complete replacement, as it does not provide VoIP, but is a +start. I may look for voice alternatives or dig deeper for a jabber client that +supports voice. + +## Previous steps (DNS and TLS) + +Some DNS configuration is needed for this guide. If you are not using file +uploads or multi-user chat, then is probably fine if your root dns name points +to the machine that will host the xmpp server. If not, you'll have to define +some SRV records, and also any record you may use for the mentioned services. +It may look like this (config depends on your DNS provider): + + _xmpp-client._tcp 1800 IN SRV 5 0 5222 server.mydomain.com. + _xmpp-server._tcp 1800 IN SRV 5 0 5269 server.mydomain.com. + +This will tell xmpp clients and other servers trying to reach your accounts +where (host and port) to knock. + +In this particular case I configured also multi-user chat and http file +uploads, so I defined `uploads`, `proxy` and `groups` as `CNAME` of the +server's `A` record. + +I also configured `acme-client(1)` and `httpd(8)` to get certificates from +letsencrypt, so all communications client/server and server/server is +encrypted. + +How to do that is out of the scope of this guide, just read the man pages, it's +quite easy to do. The only detail to take into account is that is better to +have all the domains/subdomains with its own cert and into separated folders +containing the certificate and the private key. This important for certificate +import on prosody later on. So I ended up configuring it to store certs on a +structure like: + + /etc/ssl/letsencrypt/ + |-- mydomain.com + | |-- cert.pem + | |-- fullchain.pem + | `-- privkey.pem + |-- groups.mydomain.com + | |-- cert.pem + | |-- fullchain.pem + | `-- privkey.pem + ... + +## Server install + +Install the server is as easy as: + + $ doas pkg_add prosody + +## Server config + +So here comes the fun part. + +First you should get the community modules. Some of them provide functionality +that is needed on any modern IM system. + +The way to do that is cloning the [mercurial][6] repository. I did not want to +have it installed on my server, so I cloned it on my desktop machine and synced +to the server. So, on my desktop I did: + + hg clone https://hg.prosody.im/prosody-modules/ prosody-modules + +Then I uploaded it to `/usr/local/lib/prosody-modules/` on the server. +Here's the important parts I changed from the config files and why: + +Community modules location: + + plugin_paths = { "/usr/local/lib/prosody-modules" } + +List of globally enabled modules: + + modules_enabled = { + "roster"; -- Allow users to have a roster. Recommended ;) + "saslauth"; -- Authentication for clients and servers. Recommended if you want to log in. + "tls"; -- Add support for secure TLS on c2s/s2s connections + "dialback"; -- s2s dialback support + "disco"; -- Service discovery + "carbons"; -- Keep multiple clients in sync + "pep"; -- Enables users to publish their mood, activity, playing music and more + "private"; -- Private XML storage (for room bookmarks, etc.) + "blocklist"; -- Allow users to block communications with other users + "vcard"; -- Allow users to set vCards + "version"; -- Replies to server version requests + "uptime"; -- Report how long server has been running + "time"; -- Let others know the time here on this server + "ping"; -- Replies to XMPP pings with pongs + "register"; -- Allow users to register on this server using a client and change passwords + "mam"; -- Store messages in an archive and allow users to access it + "admin_adhoc"; -- Allows administration via an XMPP client that supports ad-hoc commands + "server_contact_info"; -- Publish contact information for this service + "vcard4"; + "vcard_legacy"; + "smacks"; -- XEP-0198: Stream Management, keep chatting even when the network drops for a few seconds + "csi_simple"; + "bookmarks"; + "cloud_notify"; -- XEP-0357: Push Notifications. + } + +Disable registration, as this will not be a public server. This is the default, +but just check it just in case. + + allow_registration = false + +Force clients to use encrypted connections + + c2s_require_encryption = true + +Force servers to use encrypted connections. + + s2s_require_encryption = true + + +Force certificate authentication for server-to-server connections. This may +bring problems with servers that use self-signed certificates. Today nobody +should be using that, as there are alternatives like letsencrypt but, if you +have some server you want to talk to that uses self-signed certs, check +`s2s_insecure_domains` + + s2s_secure_auth = true + +Location of directory to find certificates in (relative to main config file), +on OpenBSD that's `/etc/prosody/certs` + + certificates = "certs" + +Virtual host. You can have many, for many domains. In my case this is just one +personal domain. I limited the uploads to 9MB, but you can set up any other +limit. Keep in mind that there's a 10MB limit for `http_max_content_size` + + VirtualHost "mydomain.com" + Component "uploads.mydomain.com" "http_upload" + http_upload_file_size_limit = 1024 * 1024 * 9 -- 9MB upload limit + Component "groups.mydomain.com" "muc" + modules_enabled = { "muc_mam", "vcard_muc" } + Component "proxy.mydomain.com" "proxy65" + +At this point you can import the certificates you got from letsencrypt (or from +any other CA), with the command: + + prosodyctl --root cert import /etc/letsencrypt/letsencrypt + +That will copy all needed files to `/etc/prosody/certs` so they are accessible +to the prosody daemon. Now you can start the daemon: + + doas rcctl start prosody + +To make it permanent on boot, add it to the `pkg_scripts` on +`/etc/rc.conf.local`. + +Also remember to open ports on the firewall (pf or any other you may have in +front of your server). They are: + + 5000 --> for proxying large file transfers between clients + 5222 --> for client to server + 5269 --> server to server + 5281 --> default https port for http file transfers + +## Add accounts and client config. + +In order to add an account to your new server just execute: + + prosodyctl adduser user@mydomain.com + +You'll be asked for the new password and that's it ! + +On the client side is usually enough to enter the jid (jabber id, in this +example `user@mydomain.com`) and the password. As we configured the necessary +dns records earlier, the client will discover to which server and port to +contact to. + +## OMEMO + +[OMEMO Multi-End Message and Object Encryption][7] is an extension to XMPP that +provides encryption for 1:1 and multi-user chats. + +This is key for a secure chat system. Some of the most popular xmpp clients +already support it. Conversations, for instance, has it enabled by default. +Do not forget to set it up on your client. + +OMEMO trusts devices on first use, then you should check the key fingerprints +to see if the person you're talking to is who it claims to be. + +Is a good practice to publish those fingerprints on some place public, like you +would do with your GnuPG public key. In fact you could sign those to provide +some proof of ownership. + +On Conversations, for instance, you can later verify a contact fingerprint via +a QR code. From that moment no other key will be allowed for that contact if +you do not explicitly allow it. I think all clients should support that ... + +## Conclusion + +Now you should have a working XMPP server. It can not only be used for IM, but +also for notifications on your scripts using the libraries for your language of +choice. Here you have some examples in [perl][9], [python][10] and [golang][11] + +--- + +[1]: https://prosody.im +[2]: https://homebrewserver.club/configuring-a-modern-xmpp-server.html +[3]: https://gajim.org/ +[4]: https://conversations.im/ +[5]: http://www.profanity.im/ +[6]: https://www.mercurial-scm.org/ +[7]: https://en.wikipedia.org/wiki/OMEMO +[8]: https://chatsecure.org/ +[9]: https://metacpan.org/pod/Net::XMPP +[10]: https://lab.louiz.org/poezio/slixmpp +[11]: https://github.com/FluuxIO/go-xmpp diff --git a/static/signify_key.pub b/src/signify_key.pub diff --git a/static/ssh_keys.pub b/src/ssh_keys.pub diff --git a/static/ssh_keys.pub.asc b/src/ssh_keys.pub.asc diff --git a/static/ssh_keys.pub.sig b/src/ssh_keys.pub.sig diff --git a/static/style.css b/src/style.css diff --git a/src/teensy-midi-controller.md b/src/teensy-midi-controller.md @@ -0,0 +1,82 @@ +# Teensy MIDI controller +2019-03-16 + +I recently discovered, and been playing with [VCV Rack][1]. This software +is just awesome. + +I knew about modular synthesizers because a friend of mine (dj and +musician) told me about it some years ago, but I never really got it. +With vcv rack you can understand how modular synthesis works, play with +it and learn a thing or two about music in general and analog signals. +It is pretty fun. Not to mention that real hardware modular is extremely +expensive and with this software option you can add as many modules as +your CPU can handle before start "glitching". + +One thing I do not like about software synths is the "abstraction". I +mean, you are point and click, so the experience is poor really, so I +thought to make a device to control some of the parameters of the +patches (that's modular jargon for a particular modular setup). + +Such devices do exist, they are called MIDI controllers, but I did not +want to spend much money on this, as I know nothing about music and they +are not super cheap. + +They send MIDI [commands][2], which is the industry standard for digital +music communication. In this case over USB instead of the traditional +serial over midi DIN cable. + +There are some easy ways to make such a device. Some Arduino compatible +development boards out there (like the [Teensy][3], LC in my case) can act +as a USB MIDI device and programming them to do basic stuff is really +easy. + +So, I got a Teensy LC (the cheapest I could find), 8 potentiometers and +4 buttons and connected them together. With a bit of [code][4] I had a +MIDI device sending MIDI CC (control) commands to the computer. Then I +just had to configure the MIDI-CC core module on vcvrack, and start +patching! + +This device is not limited to vcvrack. It can be used with any software +that accepts midi commands. + +The midi channel can be changed modifying this line on the code + + #define MIDI_CHANNEL 2 + +Same for the control commands on the pots and buttons: + + static const uint8_t potCC[NUM_POTS] = {1, 2, 3, 4, 5, 6, 7, 8}; + static const uint8_t btnCC[NUM_BUTTONS] = {11, 12, 13, 14}; + +The mode of the buttons can be one of momentary, latch or trigger and +can also be adjusted here: + + uint8_t btnMode[NUM_BUTTONS] = {MOMENTARY, TRIGGER, TRIGGER, LATCH}; + +Now I can pair real pots and buttons with some of my patch parameters +and play with it. Here's an [example][5] (yeah, I'm definitely not a +musician) + +I also designed a case for it using FreeCAD and printed it on my 3D +printer. The end result is not bad at all. I'll upload some pictures +when I have the time [here][6] + +The only problem with all this is that is highly addictive ... + +Let's see how it goes. + +Here you have more references for [Teensy USB MIDI][7] and VCV Rack +"howto's" ([1][8] and [2][9]) + +Have fun ! + +---- +[1]: https://vcvrack.com/ +[2]: https://en.wikipedia.org/wiki/MIDI +[3]: https://www.pjrc.com/teensy/ +[4]: https://git.onna.be/midi_controller/ +[5]: https://onna.be/files/vcvrack_test.mp3 +[6]: https://onna.be/files/midi_controller_pictures/ +[7]: https://www.pjrc.com/teensy/td_midi.html +[8]: https://www.youtube.com/channel/UCuWKHSHTHMV_nVSeNH4gYAg +[9]: https://www.youtube.com/channel/UCnZEv3hADF9ELOIwUNu6RVg diff --git a/static/files/cetus_config.diff b/static/files/cetus_config.diff @@ -1,102 +0,0 @@ ---- cetus_v6_config Fri Jan 18 12:40:17 2019 -+++ config Fri Jan 18 13:04:03 2019 -@@ -163,41 +163,12 @@ - - ## PID configuration - ## See http://smoothieware.org/temperaturecontrol#pid --temperature_control.hotend.p_factor 22 #23.0 --temperature_control.hotend.i_factor 1.047 #1.104 --temperature_control.hotend.d_factor 115 #120 -+temperature_control.hotend.p_factor 30.7 -+temperature_control.hotend.i_factor 1.477 -+temperature_control.hotend.d_factor 160 - --temperature_control.hotend.max_pwm 160 # max pwm, 64 is a good value if driving a 12v resistor with 24v. -+temperature_control.hotend.max_pwm 255 - --####################################### optional use underside port as 2nd extruder --# second hotend configuration --temperature_control.hotend2.enable false # Whether to activate this ( "hotend" ) module at all. --temperature_control.hotend2.thermistor_pin 0.26 # Pin for the thermistor to read --temperature_control.hotend2.heater_pin 0.4 # Pin that controls the heater, set to nc if a readonly thermistor is being defined --#temperature_control.hotend2.thermistor EPCOS100K # see http://smoothieware.org/temperaturecontrol#toc5 --temperature_control.hotend2.beta 3950 # or set the beta value --temperature_control.hotend2.set_m_code 104 # --temperature_control.hotend2.set_and_wait_m_code 109 # --temperature_control.hotend2.designator T1 # --temperature_control.hotend2.max_temp 300 # Set maximum temperature - Will prevent heating above 300 by default --temperature_control.hotend2.min_temp 20 # Set minimum temperature - Will prevent heating below if set -- --# Safety control is enabled by default and can be overidden here, the values show the defaults --# See http://smoothieware.org/temperaturecontrol#runaway --temperature_control.hotend2.runaway_heating_timeout 900 # How long it can take to heat up, max is 2040 seconds. --#temperature_control.hotend2.runaway_cooling_timeout 0 # How long it can take to cool down if temp is set lower, max is 2040 seconds --temperature_control.hotend2.runaway_range 50 # How far from the set temperature it can wander, max setting is 63°C -- --# PID configuration --# See http://smoothieware.org/temperaturecontrol#pid --#temperature_control.hotend2.p_factor 30 # P ( proportional ) factor --#temperature_control.hotend2.i_factor 0.3 # I ( integral ) factor --#temperature_control.hotend2.d_factor 300 # D ( derivative ) factor -- --##temperature_control.hotend2.max_pwm 64 # max pwm, 64 is a good value if driving a 12v resistor with 24v. --####################################### -- -- - ###################################### Cetus use the underside port as bed control enable for tinyfab heatbed driver - temperature_control.bed.enable false # Whether to activate this ( "hotend" ) module at all. - temperature_control.bed.thermistor_pin 0.26 # Pin for the thermistor to read -@@ -283,7 +254,7 @@ - endstops_enable true # The endstop module is enabled by default and can be disabled here - #corexy_homing false # Set to true if homing on a hbot or corexy - #alpha_min_endstop 1.25^ # Pin to read min endstop, add a ! to invert if endstop is NO connected to ground --alpha_max_endstop 1.24^ # Pin to read max endstop, uncomment this and comment the above if using max endstops -+alpha_max_endstop 2.13^ # Pin to read max endstop, uncomment this and comment the above if using max endstops - alpha_homing_direction home_to_max # Or set to home_to_max and set alpha_max and uncomment the alpha_max_endstop - alpha_min 0 # This gets loaded as the current position after homing when home_to_min is set - alpha_max 180 # This gets loaded as the current position after homing when home_to_max is set -@@ -296,7 +267,7 @@ - gamma_max_endstop 1.28^ # Pin to read max endstop, uncomment this and comment the above if using max endstops - gamma_homing_direction home_to_max # Or set to home_to_max and set alpha_max and uncomment the alpha_max_endstop - gamma_min 0 # This gets loaded as the current position after homing when home_to_min is set --gamma_max 190 # This gets loaded as the current position after homing when home_to_max is set -+gamma_max 180.7 # This gets loaded as the current position after homing when home_to_max is set - - alpha_max_travel 190 # Max travel in mm for alpha/X axis when homing - beta_max_travel 190 # Max travel in mm for beta/Y axis when homing -@@ -339,13 +310,13 @@ - - ## Z-probe - # See http://smoothieware.org/zprobe --zprobe.enable false # Set to true to enable a zprobe --zprobe.probe_pin 2.13 #2.13!^ # Pin probe is attached to, if NC remove the ! (2.13 = door check port) -+zprobe.enable true # Set to true to enable a zprobe -+zprobe.probe_pin 1.24!^ #2.13!^ # Pin probe is attached to, if NC remove the ! (2.13 = door check port) - zprobe.slow_feedrate 5 # Mm/sec probe feed rate - #zprobe.debounce_count 100 # Set if noisy - zprobe.fast_feedrate 100 # Move feedrate mm/sec - zprobe.probe_height 10 # How much above bed to start probe --#gamma_min_endstop nc # Normally 1.28. Change to nc to prevent conflict, -+gamma_min_endstop nc # Normally 1.28. Change to nc to prevent conflict, - - # Levelling strategy - # Example for 3-point levelling strategy, see wiki documentation for other strategies -@@ -358,6 +329,18 @@ - #leveling-strategy.three-point-leveling.probe_offsets 0,0,0 # the probe offsets from nozzle, must be x,y,z, default is no offset - #leveling-strategy.three-point-leveling.save_plane false # set to true to allow the bed plane to be saved with M500 default is false - -+leveling-strategy.rectangular-grid.enable true # The strategy must be enabled in the config, as well as the zprobe module. -+leveling-strategy.rectangular-grid.x_size 140 # size of bed in the X axis -+leveling-strategy.rectangular-grid.y_size 170 # size of bed in the Y axis -+leveling-strategy.rectangular-grid.size 7 # The size of the grid, for example, 7 causes a 7x7 grid with 49 points. -+ # Must be an odd number. -+leveling-strategy.rectangular-grid.do_home true -+leveling-strategy.rectangular-grid.probe_offsets 0,-10,0 # Optional probe offsets from the nozzle or tool head -+leveling-strategy.rectangular-grid.save true # If the saved grid is to be loaded on boot then this must be set to true -+leveling-strategy.rectangular-grid.initial_height 10 # will move to Z10 before the first probe -+#leveling-strategy.rectangular-grid.dampening_start 0.5 # compensation decrease point (optional) -+#leveling-strategy.rectangular-grid.height_limit 1 # no compensation to apply after this point (optional) -+mm_per_line_segment 1 # necessary for cartesians using rectangular-grid - - ## - # Panel See http://smoothieware.org/panel diff --git a/templates/gophermap b/templates/gophermap @@ -1,35 +0,0 @@ - __ - /\ \ - ___ ___ ___ __ \ \ \____ __ - / __`\ /' _ `\ /' _ `\ /'__`\ \ \ '__`\ /'__`\ - /\ \L\ \/\ \/\ \/\ \/\ \/\ \L\.\_ __\ \ \L\ \/\ __/ - \ \____/\ \_\ \_\ \_\ \_\ \__/.\_\/\_\\ \_,__/\ \____\ - \/___/ \/_/\/_/\/_/\/_/\/__/\/_/\/_/ \/___/ \/____/ - -o--o-- ---------------------------------------------- gopherhole -- o -- - -Sometimes I write things so I do not forget ... - -o--o-- Random (usually tech) stuff - -${articleList} - -o--o-- Ramblings - -1Phlog /phlog onna.be 70 - -o--o-- More Info - -hCode URL:https://git.onna.be/ -0Contact /contact.txt onna.be 70 -0GnuPG key /gpgkey.asc onna.be 70 -0GnuPG Keys transition statement /gpg_keys_transition.txt onna.be 70 - -o--o-- Sometimes I read ... - -1Phlogroll /phlogroll onna.be 70 -hTilde News URL:https://tilde.news/ - -o- o -- -------------------------------------------------------- -- o -- -Last updated: ${last} -o- o -- -------------------------------------------------------- -- o -- diff --git a/templates/index.html b/templates/index.html @@ -1,25 +0,0 @@ -<!DOCTYPE html> -<html> -<head> -<meta charset="utf-8" /> -<meta name="viewport" content="width=device-width,initial-scale=1" /> -<meta name="date" content="${date}" scheme="YYYY-MM-DD" /> -<meta name="author" content="paco" /> -<link rel="stylesheet" href="style.css" /> -<title>onna.be</title> -</head> -<body> - -<p>${menu}</p> - -<hr/> - -<ul> -${articleList} -</ul> - -<hr/> - -<p>Last updated: ${last}</p> -</body> -</html> diff --git a/templates/menu_template.html b/templates/menu_template.html @@ -1 +0,0 @@ -<a href="/">home</a> / <a href="https://git.onna.be/">code</a> / <a href="contact.txt">contact</a> / <a href="gpgkey.asc">GnuPG Key</a> / <a href="gpg_keys_transition.txt">Keys transition statement</a> diff --git a/templates/phlogmap b/templates/phlogmap @@ -1,13 +0,0 @@ -i----------------------------------------------------------------------- onna.be 70 -i __ __ onna.be 70 -i .-----.| |--.| |.-----.-----. onna.be 70 -i | _ || || || _ | _ | __ __ __ onna.be 70 -i | __||__|__||__||_____|___ | |__|__|__| onna.be 70 -i |__| |_____| onna.be 70 -i onna.be 70 -i----------------------------------------------------------------------- onna.be 70 -i onna.be 70 -${entryList} -i onna.be 70 -i----------------------------------------------------------------------- onna.be 70 -iLast updated: ${last} onna.be 70
