So simply joining an existing mastodon instance is not enough for you, you want control? Set up your own! The official documentation has a page about that, including listing a bunch of specialised hosting providers that will do this installation bit for you. But we like the more difficult road with the rewarding learning curve around here. Make sure you get get your linux box prepared, and we'll get into setting up a mastodon instance on local hardware, running linux, without docker, and without cloud storage.


  • Step 1; Get to installing mastodon

  • Details )


  • Step 2; Get to customising mastodon

  • Details )


  • Step 3; Should you set up an instance for other people?

  • Details )
    I don't know why I left it so long to figure out how to do this. Yes, running everything yourself on a home connection is less stable than using a hosted service. But in the spirit of making the internet more chaotic, and a bit grungier, let's do this.

    My set-up is quite specific. I bought (though rented is more correct) a domain, example.com, through my regular domain registrar. I want to run a subdomain, server.example.com, from hardware under the tv. I do not have a static ip, so I'm going to need a dynamic dns provider. I'm using dynv6, because they were the first provider recommended to me. (The irony being that in the course of this project I discovered my ISP (Internet Service Provider)'s router doesn't let me use ipv6 at all.) The hardware is something I don't want to talk about right now, but it's a linux box running a variant of debian. And I'm also using a hosted email provider that lets you bring your own domain. All accounts created and services paid for. But how does it all go together?


  • Step 1; Create the subdomain, and delegate it


  • Details )


  • Step 2; Set up your hardware on your network


  • Details )


  • Step 3; Set up ddclient on your hardware


  • Details )


  • Step 4; Optionally test it's all working


  • Details )


  • Step 5; Optionally set up email DNS records as well


  • Details )


  • Step 6; Install your server software | Choose your own adventure style


  • Whatever you are planning on doing, like apache2 or nginx, do it here. Also now is a time to think about things like iptables.


  • Step 7; Optionally run certbot


  • Details )


  • Step finally;


  • Enjoy running your server!
    Let's Encrypt's root cert expired the end of September just gone.

    For the first time since then I tried running an old python script on a Raspberry Pi. It failed with an all too familiar error message. In both python3, and with curl.

    I never see these errors in my browser (because Firefox is great like that). Even when I didn't have the certs on my site fully configured it didn't matter because Firefox had the necessary root and intermediate certs.

    So I tried curl on my Windows machine, and it worked, no errors. Okay, it's not the configuration of my site. It's the Raspberry Pi. I need to update its cert cache.

    I found most of what I needed here. The certs I want are here. (We'll be picking up local certs, so changing into the same directory is important.)

    sudo mkdir /usr/share/ca-certificates/local
    cd /usr/share/ca-certificates/local
    
    sudo wget https://letsencrypt.org/certs/isrgrootx1.pem
    sudo wget https://letsencrypt.org/certs/lets-encrypt-r3.pem
    
    sudo openssl x509 -inform PEM -in isrgrootx1.pem -outform PEM -out isrgrootx1.crt
    sudo openssl x509 -inform PEM -in lets-encrypt-r3.pem -outform PEM -out lets-encrypt-r3.crt
    
    sudo dpkg-reconfigure ca-certificates


    When prompted choose 'ask'. Mark your new certs with an asterisk, choose 'ok', and wait for it to finish.

    Test by trying that curl command again. All goes well, no more errors!

    Great, let's try that script again. Nope! More errors. Now that our Raspberry Pi has the correct certs we need to update the python certs. Enter an interactive session and find out where it keeps these certs.
    python3
    import certifi
    certifi.where()


    It says '/home/pi/.local/lib/python3.7/site-packages/certifi/cacert.pem'. Let's replace it!

    rm /home/pi/.local/lib/python3.7/site-packages/certifi/cacert.pem
    cp /etc/ssl/certs/ca-certificates.crt /home/pi/.local/lib/python3.7/site-packages/certifi/cacert.pem


    Test by trying that python3 script again. All goes well, no more errors! Hopefully for real this time.
    Go to your images. Check out the metadata;
    exiv2 image.jpg
    exiftool image.jpg

    Remove the exif data;
    exiftool -all= image.jpg
    exiftool -all= *

    You'll be left with an _original copy. If you don't need them;
    rm *_original

    Cubox Lives Again

    2018-Jan-14, Sunday 05:28 pm
    I had an idea to set up my cubox as an Android station to sync/operate all my bluetooth wearables. But neither the Android image (4.4?!) nor the Ignition installer would boot. Just sat there, glowing a red LED at me. I found their official builds server, and the only image up there for cubox is Debian. Which also doesn't work.

    Okay so. *rolls up sleeves in dramatic fashion*

    Cuboxes come with serial on by default, over the micro-USB cable.
    Find the device name;
    sudo dmesg
    Connect to serial;
    sudo screen /dev/ttyUSB0 1115200
    (If you are in Windows it's the same procedure as for Raspberry Pi.)

    U-Boot 2009.08-dirty (Jan 21 2013 - 10:57:40) Marvell version: 5.4.4 NQ SR1
    
    BootROM:
           Version on chip: 2.33
           Status: OK
           Retries #: 0
    Board: CuBox
    SoC:   88AP510 (A1)
    CPU:   Marvell Sheeva (Rev 5)
           CPU @ 800Mhz, L2 @ 400Mhz
           DDR3 @ 400Mhz, TClock @ 166Mhz
    PEX 0: interface detected no Link.
    PEX 1: interface detected no Link.
    DRAM:   2 GB
           CS 0: base 0x00000000 size  1 GB
           CS 1: base 0x40000000 size  1 GB
           Addresses 60M - 0M are saved for the U-Boot usage.
    SF: Detected W25Q32 with page size  4 kB, total  4 MB
    
    Streaming disabled 
    L2 Cache Prefetch disabled
    L2 Cache ECC disabled
    Modifying CPU/CORE/DDR power rails to 1.0(-2.5%) / 1.0(-5%) / 1.5(-5%)
    USB 0: Host Mode
    USB 1: Host Mode
    Setting VPU power OFF.
    Setting GPU power ON.
    MMC:   MV_SDHCI: 0, MV_SDHCI: 1
    Net:   egiga0 [PRIME]
    Hit any key to stop autoboot:  0 
    ===> Executing ext4load usb 0:1 0x02000000 /boot.scr
    (Re)start USB...
    USB:   Register 10011 NbrPorts 1
    USB EHCI 1.00
    scanning bus for devices... 1 USB Device(s) found
    ...
    ** Unable to use ide 0:2 for fatload **
    ===> Executing ext4load ide 0:2 0x02000000 /boot/boot.scr
    ** Bad partition 2 **
    ===> Executing fatload ide 0:2 0x02000000 /boot/boot.scr
    Error No HD connection 
    ** Can't read from device 0 **
    
    ** Unable to use ide 0:2 for fatload **
    
    egiga0 no link
    Using egiga0 device
    TFTP from server 192.168.15.100; our IP address is 192.168.15.223
    Filename 'boot.scr'.
    Load address: 0x2000000
    Loading: T T T T T T T T T T 
    Retry count exceeded; starting again


    Oh no. The very first line delivers the bad news. This machine is old. Older than I'd thought. Turns out there are two kinds of cubox; Marvell/Armada 510 CPU, and Freescale imx6 cubox-i. The former is the one I have, the latter is the only one currently supported.

    As my hardware has been abandoned by the manufacturer I'm left with Kali, Arch, or Geexbox/Kodi.

    Kali;
    Download cubox version, e.g. kali-2017.3-cubox-i.img.xz
    Extract; unxz kali-2017.3-cubox.img.xz
    Write; sudo dd if=kali-2017.3-cubox.img of=/dev/sdcard bs=512k
    Finally use gparted to expand partition to whole sdcard
    And as if by magic, the cubox boots up into Kali! (I find this especially humourous as I recently tried to create a Kali LiveUSB stick for my laptop, and couldn't get it to boot, it appears due to a lack of hardware support.)

    It doesn't help me build my Android station, but, thank you Community, for helping keep this hardware from obsolescence.
    Gizmo can speak (albeit with a new accent), and Gizmo can move, now we have to tie the two together so they only move when they speak. And it's all software.

    Again, we're following an adapted version of Furlexa project.

    First we need a python script, a more structured version of the motor/motor.py from Part 3. Separate the parts into setup(), start_furby(), and stop_furby(), and add a main(). We'll also need the sound device status file path from Part 2, /proc/asound/card0/pcm0p/sub0/status.

    furby.py )

    This script only sets the motors in motion (or stops them) based on the current state of the status file when invoked, and exits. It doesn't keep running while the motors do.

    In order to keep track of the changes of the status file a monitor script is needed. (And because we made the changes to PulseAudio in Part 2 the status will actually change.)
    output-monitor.sh )

    Make the script executable with chmod +x output-monitor.sh, and run with ./output-monitor.sh. Then make some sounds in another ssh session. There you go, singing, dancing, Gizmo!


    But hey, wouldn't it be nice to make this Gizmo's default behaviour without having to invoke it every time? Let's get it to run at startup. We're going to set it up with systemd as described here.

    systemd )

    Reboot to pickup changes. And finally, Furby/Gizmo is all singing, all dancing.

    (Small caveat; Furby/Gizmo will do a little shimmy with every pop/click out of the speaker.)

    You can install Alexa if you want, I won't be. I do have other plans to extend the project a bit but this is the bulk of the project, and plenty to freak your friends out. Bonus, you don't even have to close up and re-skin Furby/Gizmo. Don't believe me? Have a look for yourself.


    Part 1 | Part 2 | Part 3 | Part 4 | Part 5
    After disassembling Gizmo I found I needed to remove, and discard, some stuff.

    Details and pictures )

    Now, some assembly; the brain transplant.

    Brain wiring )

    Brain programming )


    Part 1 | Part 2 | Part 3 | Part 4 | Part 5
    I spent way too long trying to build a solution out of parts I had readily available before I discovered that Adafruit had exactly the thing I needed: the piOLED, tiny screen to attach to my Raspberry Pi Zero W. One of the examples even included what I was after; a way to display the ip address, in stats.py.

    The script doesn't exit as cleanly as I'd like, so the first thing is to put the while True: loop into a try: and put the cleanup in the catch:
    except KeyboardInterrupt:
        disp.clear()
        disp.display()


    The tutorial also has instructions on how to run the script on startup; by putting it in rc.local
    sudo vim /etc/rc.local
    And add the call to the script, before exit 0, pushing it into the background;
    sudo python /home/pi/Adafruit_Python_SSD1306/examples/stats.py &
    Save and exit.

    Cool, now we have a way to display the ip address of the pi so we can ssh in. But, there is nothing to turn it off again.

    First thing needed is a python script to blank the screen. You can take a copy of stats.py and strip out everything except the setup code and the cleanup code. Cool, this works, kinda. It clears for a moment and then starts displaying again. This is because we haven't killed the processes doing that yet.

    So, we write a script to do that. (Here I ran into some dash versus bash problems. Damn you dash, damn you.)
    Something like;
    #/bin/sh
    
    pids=$(ps -ef | grep 'python .*examples/stats.py' | awk '{print $2}')
    
    echo $pids | while read -r line;
    do
        sudo kill -9 $line
    done
    
    sudo python /home/pi/Adafruit_Python_SSD1306/examples/blank.py


    Great, this works wonderfully, when we manually invoke it. We're going to want it to run at shutdown too though. (Because, while power is still supplied to the pi, even though it's off, and the screen isn't updating, the old data is still displaying.)

    This is not as easy as it should be. I basically wanted a rc-local for shutting down. I'm not the only person who has had this idea, so have a look here for a way to add shutdown functionality to rc-local.

    Summary;
    * Copy /etc/rc.local to /etc/rc.local.stop
    * Edit /etc/init.d/rc.local, adding in extra info to # Required-Stop:, # Default-Stop:, edit the case statement to call do_stop in event of stop), and add the do_stop function (which is a copy of the do_start function changed to point at rc.local.stop).
    * Delete the old rc-local daemon; sudo update-rc.d -f rc.local remove
    * Pick up the new; sudo update-rc.d rc.local defaults

    But, this alone isn't enough for Debian/Raspbian to pick up the changes. Enter systemd.
    sudo vim /lib/systemd/system/rc-local.service
    And add this line just after ExecStart;
    ExecStop=/etc/rc.local.stop stop
    Save and exit.

    Now, stop the daemon, reload it, and then start it.
    sudo systemctl stop rc-local
    sudo systemctl daemon-reload
    sudo systemctl start rc-local


    One final thing, edit rc.local.stop to use the stop script instead of the start one. And don't push it to the background. Something like;
    sudo /home/pi/Adafruit_Python_SSD1306/examples/kill_SSD1306.sh

    Finally, when you reboot, startup, and all the other fun things the screen should behave nicely. Enjoy.
    Okay. Hi. Yes, I'm still here. It's been an eventful err, many months. But more about that another time. Maybe.

    Well, either that, or, I only post once in a Blue Moon! (Sorry, couldn't resist.)

    Last year at EMF I picked up a BeagleBone Black (rev C). This week I actually unpacked it and powered it up. I was pleasantly surprised to find that the rev C ships with Debian installed, but that means most of the documentation online (and on the BBB) is slightly out of date. No worries; things are actually simpler now!

    Even though it shipped with Debian when I tried to apt-get update/upgrade/install I got errors. So there was only one thing for it; flash the onboard memory. When I went about this I found that the source of online documentation was (is?) offline. And the wayback machine was only serving up some too-old files. Luckily I found a chap with a link to the most recent eMMC flasher image! I've said it before, and I'll say it again, yay for bloggers!

    One thing that tripped me up; when writing the image to the SD card, on Windows you need to run the program As Administrator for sufficient privileges. Learn from my mistakes friends. Also, only hold down the SD button until the 4-LEDs start to flash, then let go. The rest is smooth sailing.

    When you boot up, you ssh in (over the USB cable); as root, with no password. Set one immediately! Then you do all the usual configuration things;
    set a nice hostname - vim /etc/hostnames, vim /etc/hosts
    add a non-root user - adduser, visudo
    setup wireless - vim /etc/network/interfaces (unfortunately it involves hardcoding your password)

    (I got a raspberry pi wireless dongle to use with my cubox, and now my BBB. Poor thing has never meet a raspberry pi. ... Speaking of the cubox; arch linux turned out to be just too much effort. Will probably throw Debian on there as well.)

    Then reboot, and if ifconfig doesn't show an ip-address try ifup wlan0. Once online apt-get update, apt-get upgrade. And just like that you have a fully functioning Debian server (with broken out physical pins) to bend to your will. I have to say, it is one of the easiest setups I have encountered with microcontrollers/embedded systems. And a good first impression means a lot. I look forward to playing with it more.

    *edit 2015-09-16*
    Setting up my second BBB was far more troublesome! I finally got it working; using dd in linux, onto an 8gb micro sdcard (my 4gb must have a .1 or .2 too small), and even though the file (from here) is named 2015-03-01 the installation reports 2015-07-17. Curiouser and curiouser.

    New Gadget; CuBox

    2014-Jun-30, Monday 08:35 pm
    I've always wanted my own server. Although I haven't exactly had much need for one. Then I heard about these little beauties; the CuBox (or rather one with the older chipset). For some scale here it is next to a 250ml teapot and a one-Euro coin.

    CuBox next to a 250ml glass teapot and one-Euro coin

    Just too cute
    Photo by chebe



    It arrived with Ubuntu (10.04!) installed, which would just not do. So I copied all the cool kids and installed Arch linux on it. For that extra-low-level feel. I actually used the CuBox installer, which was very simple to use. But Arch is very stripped down, so I then had the fun of installing all the things I normally take for granted. Like vim, and sudo. Though to be fair, once I figured out that the package manager was called pacman, and an update is just pacman -Syu, things got much easier.

    I've configured it up as a DNS server, and installed this dotey USB wifi dongle. So now it can sit happily next to the power socket (all the other cables unplugged), and I can ssh in to it. I'm still not sure what, if anything, I need it for, but at the very least I'm going to play around with mongodb and django for a bit.

    Profile

    chebe: (Default)
    chebe

    Syndicate

    RSS Atom

    June 2025

    M T W T F S S
          1
    23 45678
    9101112131415
    16171819202122
    23242526272829
    30      

    Expand Cut Tags

    No cut tags

    Style Credit