-
In
~/.ssh/config
, include the lines:Host * ControlPath ~/.ssh/sockets/%r@%h-%p
weechat | |
Relay setup | |
On the server's instance of weechat: | |
/relay add ssl.irc 8001 | |
/secure set relay WHATEVER_PASSWORD | |
/set relay.network.password "${sec.data.relay}" | |
On the server, to generate the ssl certificate: |
version: '2' | |
services: | |
minio: | |
image: minio/minio | |
container_name: miniobkp | |
ports: | |
- 9000:9000 | |
env_file: | |
- ./minio.env |
The Shields service (at shields.io) provides a way to create custom badges for your projects. These are badges are very common and are frequently used to show status information about the project, or demonstrate tools that were used for the development of your project.
# This isn't meant to be ran as a script, but line-by-line | |
# Props to Binary (benary.org) for helping me with this | |
# 0: Create a Scaleway instance and SSH into it | |
ssh root@... | |
# 1: Install Nix | |
adduser user # set a password, doesn't matter what because it's not staying long | |
adduser user sudo | |
su -l user |
# Get ISO and verify signature | |
# - https://wiki.archlinux.org/index.php/Installation_guide#Verify_signature | |
# ============================ | |
# https://www.archlinux.org/download/ | |
gpg --keyserver-options auto-key-retrieve --verify archlinux-version-x86_64.iso.sig | |
# Preparing bootable USB | |
# - https://wiki.archlinux.org/index.php/USB_flash_installation_medium#Using_basic_command_line_utilities | |
# ====================== |
# sudo /sbin/rcvboxdrv -h | |
# Unloading modules: | |
# Loading modules: modprobe: FATAL: Module vboxnetadp not found in directory /lib/modules/4.4.3-1-ARCH | |
# modprobe: FATAL: Module vboxnetflt not found in directory /lib/modules/4.4.3-1-ARCH | |
# modprobe: FATAL: Module vboxpci not found in directory /lib/modules/4.4.3-1-ARCH | |
# modprobe: FATAL: Module vboxdrv not found in directory /lib/modules/4.4.3-1-ARCH | |
# Solution | |
# from https://forum.antergos.com/topic/818/can-t-run-my-vitualbox/4 |
Services declared as oneshot
are expected to take some action and exit immediatelly (thus, they are not really services,
no running processes remain). A common pattern for these type of service is to be defined by a setup and a teardown action.
Let's create a example foo
service that when started creates a file, and when stopped it deletes it.
Create executable file /opt/foo/setup-foo.sh
:
Create a template service file at /etc/systemd/system/[email protected]
. The template parameter will correspond to the name
of target host:
[Unit]
Description=Setup a secure tunnel to %I
After=network.target