Host:Extern: Difference between revisions

From Chaosdorf Wiki
Jump to navigation Jump to search
m (admins)
(23 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{Host
{{Host
|name=extern.chaosdorf.de
|name=extern.chaosdorf.de
|location={{H|vm}}
|os=Debian Buster amd64
|location=Host:Vm
|purpose=öffentliche Dienste
|purpose=öffentliche Dienste
|os=Debian Squeeze amd64
|disk=20GB
|disk=20G
|ram=4GiB
|ram=1G
|swap=4GB
|admin_toolkit=Yes
|ssh_root_keys=/var/cache/ssh
|ssh_root_keys=/var/cache/ssh
|ssh_pam=yes
|ssh_pam=Yes
|ssh_userlogin=SFTP only
|ssh_userlogin=No
|admins=byte, derf, mxey
|admins=byte,derf,feuerrot
}}
}}
== Mediawiki ==


= Mediawiki =
''wiki.chaosdorf.de'' (aka "dieses").
 
Standardsetup mit nginx, php-fpm und MySQL.
 
[[Special:Version]] (inkl. Extensions) / [[Special:Statistics]] (inkl. Admins)
 
Extensions werden bevorzugt per Tarball installiert / aktualisiert. Per Composer installierte Extensions müssen in composer.local.json eingetragen werden.
 
Wir nutzen folgende nicht im Mediawiki-Release enthaltene Extensions:
 
* MobileFrontend für Handy- und Tabletsupport (tarball)
* LDAPAuthentication2 (+PluggableAuth+LDAPProvider) (tarball)
* SemanticMediaWiki für [[Projects]], [[Resources]] u.ä. (composer)
* PageForms um Templates per Formular statt Plaintext bearbeiten zu können (tarball)
 
Und folgende nicht im Mediawiki-Release enthaltene Skins:
 
* MinervaNeue für das Mobile Frontend (tarball)
 
=== Wiki aktualisieren ===
 
* Neues Mediawiki-Release als Tarball laden
* SMW deaktivieren (enableSemantics in den LocalSettings auskommentieren, composer.local.json löschen/umbenennen)
* Mediawiki wie in der Doku beschrieben aktualisieren (Tarball entpacken, php maintenance/update.php)
* SMW aktualisieren (neue Version in composer.local.json eintragen, <tt>sudo -u www-data composer update --no-dev</tt>, SMW-spezifische Maintenance-Skripte ausführen)
* Nicht im Mediawiki-Release enthaltene Extensions aktualisieren (Tar-Archive runterladen und entpacken)


''wiki.chaosdorf.de'' (aka "dieses").
=== SMW updaten ===


Standardsetup mit Apache und MySQL. [https://wiki.chaosdorf.de/index.php?title=Special:ListUsers&group=sysop Admins].
Ist frickelig. <tt>cd /srv/www/de.chaosdorf.wiki</tt>, Version in composer.local.json ändern, <tt>sudo -u www-data composer update --no-dev</tt>.


== Login ==
=== Login ===


Per LDAP ("Chaosdorf"), alternativ mit eigens registriertem Account ("local").
Per LDAP ("Chaosdorf"), alternativ mit eigens registriertem Account ("local").
Line 24: Line 52:
Anonyme Edits sind erlaubt.
Anonyme Edits sind erlaubt.


== Captcha ==
=== Kalender ===
 
Auf {{H|shells}} läuft alle 5 Minuten [https://github.com/chaosdorf/wikicron/blob/master/extern/current_events wikicron/current_events] über {{U|derf}}s crontab, welches [[Chaosdorf_Wiki:Current_events]], [[Template:Current_events_preview]] und [[Chaosdorf_Wiki:Past_events]] generiert. Es erzeugt ebenfalls ein ical, welches per scp auf <https://chaosdorf.de/~derf/cccd.ics> landet.
 
== Wordpress ==
 
Installiert in <tt>/srv/www/de.chaosdorf</tt>, enthält ein Git-Repo zum Tracken der Installation. Die Nutzdaten liegen in der lokalen MySQL-Datenbank <tt>wordpress</tt>.
 
=== Updates ===
 
Ein Icinga-Check meldet sich bei anstehenden Updates, installiert werden diese ganz normal über das Webinterface. Nach dem Updaten: Per SSH auf <tt>extern:/srv/www/de.chaosdorf</tt> verbinden und die Änderungen committen (<tt>git add -A .; git commit -m 'wordpress updates'</tt>). Teilweise muss man zuvor von Hand <tt>/srv/www/de.chaosdorf/.maintenance</tt> löschen (irgendwas ist beim Wordpress im Argen…).


Wir benutzen [http://www.mediawiki.org/wiki/Extension:QuestyCaptcha ConfirmEdit/QuestyCaptcha] zum Schutz vor Spam.
== WWW-Userdirs ==
Wenn ein anonymer User eine Seite bearbeitet oder sich registriert muss er eine vom Admin konfigurierte Frage beantworten; Aktionen von eingeloggten
Usern sind captcha-frei.


Konfiguration in /etc/mediawiki/LocalSettings.php gegen Ende.
Nutzer können sich per SFTP einloggen (z.B. 'lftp sftp://''user''@extern.chaosdorf.de'). Wenn sie dort Dateien in public_html ablegen, sind diese unter <nowiki>https://chaosdorf.de/~</nowiki>''user'' erreichbar.


Zuerst war MathCaptcha drin, es stellte sich als nicht sehr effektiv heraus.
Über /etc/pam.d/sshd wird /usr/local/sbin/addquota ausgeführt, um für neue User (!= root) einmalig ein Quota zu setzen.


== Twitterfeed ==
== Raumstatus ==


Die RecentChanges (abzüglich minor edits) unseres Wikis landen auf [https://twitter.com/#!/chaosdorf_wiki @chaosdorf_wiki]. Für eine direkte RecentChanges → Twitter-Extension ist unser Mediawiki zu alt, deshalb wird rss + twitterfeed benutzt.
Per Cronjob werden jede Minute Tür- und Raumstatus von {{H|feedback}} angefragt, anhand dessen wird [https://chaosdorf.de/raumstatus/status.png https://chaosdorf.de/raumstatus/status.png] auf ein passendes Bild gesymlinkt. Die Skripte und Bilder finden sich unter [https://github.com/chaosdorf/chaosdorf-admin-toolkit/tree/master/raumstatus chaosdorf-admin-toolikt/raumstatus] und können per <tt>fab deploy_raumstatus</tt> ausgerollt werden.


Per crontab läuft halbstündlich [https://github.com/chaosdorf/chaosdorf-admin-toolkit/blob/master/wiki/twitterfeed_update twitterfeed_update], welches ein aufbereitetes recentchanges-rss unter [http://wiki.chaosdorf.de/twitterfeed.rss /twitterfeed.rss] bereitstellt.
== Dashboard ==
Aus <nowiki><description></nowiki> wird alles bis auf die erste Zeile (Edit Summary) entfernt, damit "← Previous Revision" etc. nicht auf twitter landen.


= Wordpress =
[https://chaosdorf.de/dashboard dashboard.chaosdorf.de] wird per nginx-Proxy an {{H|dashboard}} weitergereicht.


''to be installed''
== Prosody ==


= WWW-Userdirs =
Die Konfiguration liegt in <tt>/etc/prosody/prosody.cfg.lua</tt>, der VHost chaosdorf.de in <tt>/etc/prosody/conf.d/chaosdorf.de.cfg.lua</tt>. Es sind keine NS-Records eingerichtet.


Nutzer können sich per SFTP auf frontend einloggen. Wenn sie dort Dateien in
Eine offene Registrierung von Accounts ist aus Ressourcengründen nicht erlaubt. Account anlegen: <tt>fab jabber_adduser:''foo''</tt> lokal oder <tt>sudo -u prosody prosodyctl adduser ''foo''@chaosdorf.de</tt> auf extern.
public_html ablegen, sind diese unter <nowiki>https://chaosdorf.de/~</nowiki>''user''
erreichbar.


Über /etc/pam.d/sshd wird /usr/local/sbin/addquota ausgeführt, um für neue
== TLS ==
User (!= root) einmalig ein Quota zu setzen.


Das TLS-Zertifikat für nginx und prosody wird einmal monatlich per certbot (LetsEncrypt) erneuert. Über <tt>/etc/crontab</tt> wird dazu <tt>/usr/local/sbin/refresh-tls-cert</tt> aufgerufen, was per certbot das Zertifikat erneuert und nginx sowie prosody neustartet. Wir nutzen einen nicht ganz üblichen certbot-Workflow mit von uns manuell erstelltem CSR, da wir so einen ECDSA-Key für unser Zertifikat nutzen können.


[[Category:Administration]]
[[Category:Administration]]

Revision as of 08:56, 10 April 2020

extern.chaosdorf.de
Ort Host:Vm
Zweck öffentliche Dienste
OS Debian Buster amd64
Disks 20GB20,000 MB <br />20,000,000 kB <br />0.02 TB <br />
RAM 4GiB4,096 MiB <br />4,194,304 kiB <br />4,294,967,296 B <br />0.00391 TiB <br />4,294.967 MB <br />
Swap 4GB4,000 MB <br />4,000,000 kB <br />0.004 TB <br />
Admin-Toolkit Yes
ssh key path /var/cache/ssh
PAM? Yes
SSH user login? No
Admins byte, derf, feuerrot

Mediawiki

wiki.chaosdorf.de (aka "dieses").

Standardsetup mit nginx, php-fpm und MySQL.

Special:Version (inkl. Extensions) / Special:Statistics (inkl. Admins)

Extensions werden bevorzugt per Tarball installiert / aktualisiert. Per Composer installierte Extensions müssen in composer.local.json eingetragen werden.

Wir nutzen folgende nicht im Mediawiki-Release enthaltene Extensions:

  • MobileFrontend für Handy- und Tabletsupport (tarball)
  • LDAPAuthentication2 (+PluggableAuth+LDAPProvider) (tarball)
  • SemanticMediaWiki für Projects, Resources u.ä. (composer)
  • PageForms um Templates per Formular statt Plaintext bearbeiten zu können (tarball)

Und folgende nicht im Mediawiki-Release enthaltene Skins:

  • MinervaNeue für das Mobile Frontend (tarball)

Wiki aktualisieren

  • Neues Mediawiki-Release als Tarball laden
  • SMW deaktivieren (enableSemantics in den LocalSettings auskommentieren, composer.local.json löschen/umbenennen)
  • Mediawiki wie in der Doku beschrieben aktualisieren (Tarball entpacken, php maintenance/update.php)
  • SMW aktualisieren (neue Version in composer.local.json eintragen, sudo -u www-data composer update --no-dev, SMW-spezifische Maintenance-Skripte ausführen)
  • Nicht im Mediawiki-Release enthaltene Extensions aktualisieren (Tar-Archive runterladen und entpacken)

SMW updaten

Ist frickelig. cd /srv/www/de.chaosdorf.wiki, Version in composer.local.json ändern, sudo -u www-data composer update --no-dev.

Login

Per LDAP ("Chaosdorf"), alternativ mit eigens registriertem Account ("local").

Anonyme Edits sind erlaubt.

Kalender

Auf shells läuft alle 5 Minuten wikicron/current_events über derfs crontab, welches Chaosdorf_Wiki:Current_events, Template:Current_events_preview und Chaosdorf_Wiki:Past_events generiert. Es erzeugt ebenfalls ein ical, welches per scp auf <https://chaosdorf.de/~derf/cccd.ics> landet.

Wordpress

Installiert in /srv/www/de.chaosdorf, enthält ein Git-Repo zum Tracken der Installation. Die Nutzdaten liegen in der lokalen MySQL-Datenbank wordpress.

Updates

Ein Icinga-Check meldet sich bei anstehenden Updates, installiert werden diese ganz normal über das Webinterface. Nach dem Updaten: Per SSH auf extern:/srv/www/de.chaosdorf verbinden und die Änderungen committen (git add -A .; git commit -m 'wordpress updates'). Teilweise muss man zuvor von Hand /srv/www/de.chaosdorf/.maintenance löschen (irgendwas ist beim Wordpress im Argen…).

WWW-Userdirs

Nutzer können sich per SFTP einloggen (z.B. 'lftp sftp://user@extern.chaosdorf.de'). Wenn sie dort Dateien in public_html ablegen, sind diese unter https://chaosdorf.de/~user erreichbar.

Über /etc/pam.d/sshd wird /usr/local/sbin/addquota ausgeführt, um für neue User (!= root) einmalig ein Quota zu setzen.

Raumstatus

Per Cronjob werden jede Minute Tür- und Raumstatus von feedback angefragt, anhand dessen wird status.png auf ein passendes Bild gesymlinkt. Die Skripte und Bilder finden sich unter chaosdorf-admin-toolikt/raumstatus und können per fab deploy_raumstatus ausgerollt werden.

Dashboard

dashboard.chaosdorf.de wird per nginx-Proxy an dashboard weitergereicht.

Prosody

Die Konfiguration liegt in /etc/prosody/prosody.cfg.lua, der VHost chaosdorf.de in /etc/prosody/conf.d/chaosdorf.de.cfg.lua. Es sind keine NS-Records eingerichtet.

Eine offene Registrierung von Accounts ist aus Ressourcengründen nicht erlaubt. Account anlegen: fab jabber_adduser:foo lokal oder sudo -u prosody prosodyctl adduser foo@chaosdorf.de auf extern.

TLS

Das TLS-Zertifikat für nginx und prosody wird einmal monatlich per certbot (LetsEncrypt) erneuert. Über /etc/crontab wird dazu /usr/local/sbin/refresh-tls-cert aufgerufen, was per certbot das Zertifikat erneuert und nginx sowie prosody neustartet. Wir nutzen einen nicht ganz üblichen certbot-Workflow mit von uns manuell erstelltem CSR, da wir so einen ECDSA-Key für unser Zertifikat nutzen können.