I Make Computer Beep Boop Beep
Nach der Installation von PopOS auf meinem Rechner erschien der GDM Login Screen immer auf dem 2. Monitor. Das geht ja garnicht! Um den GDM passend zu konfigurieren braucht es nur ein paar Schritte:
Das Config File in den GDM Folder kopieren:
cp ~/.config/monitors.xml ~gdm/.config/
Logout
Danach erscheint der GDM Loginscreen auf dem richtigen Monitor.
Nach dem letzten Container Update der Nextlcoud App, war bei meiner Instanz kein Einloggen mehr möglich. Es begrüßte lediglich eine "Interner Severfehler" Seite nach dem klick auf Anmelden.
Ein wenig recherche und das setzen von Loglevel 0 in der Nextcloud Config ergaben einen merkwürdigen Fehler in der Datenbank.
4047 InnoDB refuses to write tables with ROW_FORMAT=COMPRESSED or KEY_BLOCK_SIZE
Um den Fehler zu beheben (und gleichzeitig die 4 Byte Unterstützung zu aktivieren) geht man folgendermaßen vor:
In der docker-compose folgende Zeile zur DB hinzufügen:
command: --innodb-read-only-compressed=OFF
Und dann :
DB_CONTAINER=next-devmydomaincom_db_1
APP_CONTAINER=next-devmydomaincom_app_1
MYSQL_ROOT_PASSWORD=***mysecret_pass***
docker exec $DB_CONTAINER mysql nextcloud -p$MYSQL_ROOT_PASSWORD -e "show variables like 'innodb_file_format';"
docker exec --user www-data $APP_CONTAINER php occ maintenance:mode --on
docker exec $DB_CONTAINER mysql nextcloud -p$MYSQL_ROOT_PASSWORD -e "ALTER DATABASE nextcloud CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;"
docker exec --user www-data $APP_CONTAINER php occ config:system:set mysql.utf8mb4 --type boolean --value="true"
docker exec --user www-data $APP_CONTAINER php occ maintenance:repair --include-expensive
docker exec --user www-data $APP_CONTAINER php occ maintenance:mode --off
Danach lief die Nextcloud wieder problemlos.
Bei einer default Installation des NGINX Proxy und der Nextcloud als Docker-Container begrüßt einen die Einstellungs-Übersicht direkt mit den Fehlermeldungen:
Your web server is not properly set up to resolve “/.well-known/caldav”. _
Das Problem zu lösen ist easy:
die entsprechenden Einträge hinzufügen:
location /.well-known/carddav { return 301 $scheme://$host/remote.php/dav; }
location /.well-known/caldav { return 301 $scheme://$host/remote.php/dav; }
Die Proxy-Container neustarten mit docker-compose restart
Und die Fehler sind verschwunden.
Ab in die bashrc damit.
echo alias occ='docker exec -it -u www-data nextcloud-app php occ' >> ~/.bashrc
Und reload
. ~/.bashrc
TADA!
Ab und an braucht man sie einfach: URL Shortener die aus ellenlangen URLs (wie sie z.B. Sharry erzeugt) eine kurze URL zaubern.
Nach etwas Recherche bin ich auf Polr gestoßen. Polr ist klein, einfach gehalten, macht genau das was es soll und sonst nichts. Die Installation und Konfiguration geht flott und so hat man innerhalb von 5 Minuten einen eigenen Shortener Server laufen.
Bevor man mit der Installation startet, sollte man sich eine passende Subdomain anlegen, über welche Polr erreichbar ist.
Danach kann man auch schon loslegen. Ein passendes Docker-Image gibt es von ajanvier. Einfach per wget die docker-compose.yml und die .env ziehen, bearbeiten und starten. That's it!
In meinem Fall habe ich ein eigenes Netzwerk für Polr und den dazugehörigen MariaDB Container konfiguiert. Polr selbst hängt zusätzlich noch im nginx-proxy Netz um von Außen erreichbar zu sein.
docker-compose.yml
version: '3.7'
services:
polr:
image: ajanvier/polr
container_name: polr-app
env_file:
- .env
depends_on:
- mariadb
networks:
- polr-net
- nginx-proxy
mariadb:
image: mariadb
container_name: polr-mariadb
restart: always
expose:
- "3306"
environment:
- MYSQL_ROOT_PASSWORD=${DB_ROOT_PASSWORD}
- MYSQL_DATABASE=${DB_DATABASE}
- MYSQL_USER=${DB_USERNAME}
- MYSQL_PASSWORD=${DB_PASSWORD}
volumes:
- /var/lib/mysql
networks:
- polr-net
networks:
polr-net:
nginx-proxy:
external:
name: nginx-proxy
.env
Durch die Option "SETTING_SHORTEN_PERMISSION=true" können nur registrierte User Links anlegen. Die Maileinstellungen sind auch erst dann wichtig, wenn man vor hat verschiedene Benutzer anzulegen. Das ist beim mir nicht der Fall, also bleibt Mail deaktiviert.
# Database
DB_HOST=mariadb
DB_PORT=3306
DB_DATABASE=polr
DB_USERNAME=polr
DB_PASSWORD=<DBPASSWORD>
DB_ROOT_PASSWORD=<DBROOTPASSWORD>
# Admin
ADMIN_USERNAME=admin
ADMIN_PASSWORD=<ADMINPASSWORD>
ADMIN_EMAIL=<ADMINMAIL>
# Configs
APP_NAME="NossCo Shorturl"
APP_PROTOCOL=https://
APP_ADDRESS=s.nossco.de
POLR_ALLOW_ACCT_CREATION=false
POLR_ACCT_ACTIVATION=false
POLR_ACCT_CREATION_RECAPTCHA=false
POLR_RECAPTCHA_SITE_KEY=
POLR_RECAPTCHA_SECRET=
POLR_BASE=62
SETTING_PUBLIC_INTERFACE=true
SETTING_SHORTEN_PERMISSION=true
SETTING_INDEX_REDIRECT=
SETTING_REDIRECT_404=
SETTING_PASSWORD_RECOV=
SETTING_AUTO_API=false
SETTING_ANON_API=
SETTING_ANON_API_QUOTA=
SETTING_PSEUDORANDOM_ENDING=false
SETTING_ADV_ANALYTICS=false
SETTING_RESTRICT_EMAIL_DOMAIN=
SETTING_ALLOWED_EMAIL_DOMAINS=
MAIL_HOST=
MAIL_PORT=
MAIL_USERNAME=
MAIL_PASSWORD=
MAIL_FROM_ADDRESS=
MAIL_FROM_NAME=
# NGINX
VIRTUAL_HOST=s.nossco.de
LETSENCRYPT_HOST=s.nossco.de
LETSENCRYPT_EMAIL=<MAIL>
Nachdem die Konfiguration steht, pullen wir die Images und starten danach die Container.
# docker-compose pull
# docker-compose up -d
Nach ein paar Minuten sollte der Proxy die LE-Zertifikate gezogen haben und wir können uns das Ergebnis anschauen.
Auf der Sucher nach einer Lösung um schnell Dateien teile zu können (wie z.B. WeTransfer) bin ich auf Sharry von eikek gestoßen.
Es biete genau die Funktionen die ich brauche:
Die Installation & Konfiguration ist dank docker-compose und der sehr guten Dokumentation von eikek ein Kinderspiel. Es werden nur zwei Dateien angelegt (docker-compose.yml & sharry.conf) und fertig ist die Geschichte.
In meinem Setup verbindet sich der Sharry-Container mit drei Netzwerken:
docker-compose.yml
version: '3.7'
services:
restserver:
image: eikek0/sharry:latest
container_name: sharry
command: /opt/sharry.conf
volumes:
- ${PWD}/sharry.conf:/opt/sharry.conf
depends_on:
- db
networks:
- sharry-net
- nginx-proxy
- mailcow-net
environment:
- VIRTUAL_HOST=<URL>
- LETSENCRYPT_HOST=<URL>
- LETSENCRYPT_EMAIL=<mail>
db:
image: postgres:13.3
container_name: postgres_db
volumes:
- postgres_data:/var/lib/postgresql/data/
environment:
- POSTGRES_USER=dbuser
- POSTGRES_PASSWORD=<DB-PW>
- POSTGRES_DB=dbname
networks:
- sharry-net
volumes:
postgres_data:
networks:
sharry-net:
nginx-proxy:
external:
name: nginx-proxy
mailcow-net:
external:
name: mailcowdockerized_mailcow-network
sharry.conf
sharry.restserver {
base-url = "https://<URL>"
bind {
address = "0.0.0.0"
port = 9090
}
webapp {
app-name = "NossCo Sharry"
default-language = "de"
}
backend {
auth {
fixed.enabled = true ## enabled admin:admin access
}
jdbc {
url = "jdbc:postgresql://db:5432/dbname"
user = "dbuser"
password = "<DB-PW>"
}
signup {
mode = "closed"
invite-time = "14 days"
invite-password = "generate-invite"
}
mail {
enabled = true
smtp {
host = "postfix-mailcow"
port = "587"
ssl-type = "starttls"
check-certificates = false
timeout = "10 seconds"
default-from = "<MAILADRESS>"
user = "<MAILUSER>"
password = "<MAIL-PW>"
list-id = "Sharry"
}
}
}
}
Nachdem beide Dateien erstellt wurden, pullt man die benötigten Images
docker-compose pull
und startet danach das erste mal die Container.
docker-compose up
Beim ersten Start wird die Datenbank angelegt und (zumindest bei mir) wars das dann. Kein Start der App. Naja, reboot tut gut ... also mit CTRL-C die Container gekillt und neu gestartet und gleich in den Hintegrund verbannt.
docker-compose up -d
Siehe da! Es funktioniert!
Die default Logindaten sind admin:admin. Nach dem Login direkt einen neuen Benutzer anlegen, Adminrechte und Passwort vergeben, umloggen und den default Admin löschen. Dann kann nichts mehr schief gehen.
Links:
