-
- Always look for the official documentation, this tutorial may not suit you as there are new updates to the installation process.
- References are at the end of the document.
#!/bin/bash | |
cd /home/mastodon/live | |
bin/tootctl media remove --days=7 | |
bin/tootctl preview-cards remove --days=7 | |
bin/tootctl statuses remove --days=3 | |
bin/tootctl media remove-orphans |
There is already a guide on scaling your Mastodon server up. This is a short guide on scaling your Mastodon server down.
I.e., maybe you want to run a small instance of <100 active users, and you want to keep your cloud costs reasonable.
So you might be running everything on a single machine, with limited memory and CPU. (In my case, I was using a t3.medium
instance with 2 vCPUs and 4GB of RAM.) How
do you do this?
Note that I'm not a Ruby or Sidekiq expert, and most of this stuff I figured out through trial and error.
#!/bin/sh | |
curl -s https://bunnycdn.com/api/system/edgeserverlist -H "Accept: application/json" | jq -r .[] > /tmp/bunny_ips | |
echo "" >> /tmp/bunny_ips | |
curl -s https://bunnycdn.com/api/system/edgeserverlist/ipv6 -H "Accept: application/json" | jq -r .[] >> /tmp/bunny_ips | |
for ip in `cat /tmp/bunny_ips`; do ufw allow proto tcp from $ip comment 'Bunny IP'; done; |
blueprint: | |
name: Low battery level detection & notification for all battery sensors | |
description: Regularly test all sensors with 'battery' device-class for crossing | |
a certain battery level threshold and if so execute an action. | |
domain: automation | |
input: | |
threshold: | |
name: Battery warning level threshold | |
description: Battery sensors below threshold are assumed to be low-battery (as | |
well as binary battery sensors with value 'on'). |
TL;DR: Still open - see below.
This morning I woke up to some not-so-nice surprise - my 2018 MPB 13" would be kind of totally unusable. The accountsd process was stable at 400%, battery was going like ice-cream in the Sahara, and opening up LibreOffice was like a major achievement.
I did check the logs (that were growing at like 500 lines per second) and I saw a lot of lines at FAULT level:
fault 07:54:04.271342+0200 accountsd Unentitled access by client 'CallHistoryPlugi' (selector: accountsWithAccountType:handler:)
#!/bin/bash | |
# Make sure your Android device is plugged in and accessible over adb. | |
#### Remember to enable virtual displays in xorg by adding the following to your configuration (e.g. /usr/share/X11/xorg.conf.d/20-virtual.conf) | |
# Section "Device" | |
# Identifier "intelgpu0" | |
# Driver "intel" | |
# Option "VirtualHeads" "1" | |
#EndSection |
#!/bin/bash | |
# NAS IP: 192.168.1.10 in this example | |
# DHCP scope reservation for macvlan: 192.168.1.210/28 (Details below) | |
## Network: 192.168.1.210/28 | |
## HostMin: 192.168.1.211 | |
## HostMax: 192.168.1.224 | |
## Hosts/Net: 14 | |
# Create a Synology macvlan0 bridge network attached to the physical eth0, and add the ip range scope (sudo) |
{ | |
"service": { | |
"nat": { | |
"rule": { | |
"1": { | |
"description": "Redirect DNS requests", | |
"destination": { | |
"port": "53" | |
}, | |
"inbound-interface": "eth1", |
Download the latest ugw3
package from https://github.com/Lochnair/vyatta-wireguard/releases and install it on your USG using dpkg -i wireguard-ugw3-<version>.deb
.
cd /config/auth
umask 077
mkdir wireguard
cd wireguard
wg genkey > wg_private.key
wg pubkey < wg_private.key > wg_public.key