Hostsharing Wiki - Benutzerbeiträge [de]

Domains

2024-01-06T17:18:37Z

Edv38: 404 Link auf Kerndoku gefixt

{{HSDoku-DomainLinks}}
__NOTOC__

= Domains bei Hostsharing =

Die Domainverwaltung bei Hostsharing ist in zwei unabhängige Bereiche aufgeteilt:

* Die '''Domaineinrichtung''' in den HS-Paketen, zur Erstellung des Domainverzeichnisses unter [[~/]]doms im Paket und [[Aufschaltung]] einer Domain auf HS [[DNS|Name]]-, Mail- und Webserver. Dies geschieht mit [[hsadmin]] im Webfrontend oder auf der Kommandozeile.

* Das '''[http://www.domain-bestellsystem.de Domainbestellsystem]''' des HS-Partnerunternehmens Partnergate zur [[Konnektierung]], also der eigentlichen Registrierung von Domains bei einem Registrar, und zur Vergabe weiterer Aufträgen an Registrierungstellen. Jedes Mitglied von Hostsharing erhielt für dieses Domainbestellsystem Zugangsdaten, bestehend aus einem Benutzernamen der Form hs-xyz und einem Passwort.

Bei anderen Hostern ist eine Domainbestellung teilweise eine feste Kopplung der Registrierung einer Domain mit Konnektierung und gleichzeitiger Aufschaltung auf bestimmte Nameserver und Webpakete. HS ist hier wesentlich flexibler. Der über HS angebotene Zugang zum Domain-Bestellsystem erlaubt es, Domains zu registrieren und auf frei wählbare DNS-Server zu konnektieren. Auf den HS Nameservern und Paketen lassen sich gleichzeitig beliebige weltweit registrierbare Domains einrichten. Hostsharing unterstützt damit die Einrichtung und den Betrieb von Domains die von beliebigen (auch sehr exotischen) Registrierungsstellen verwaltet und abgerechnet werden können.

= Aktionen =

Typische Domainaktionen beinhalten also koordinierte Änderungen sowohl in der Domainregistrierung als auch der HS-Einrichtung, wie in folgenden Seiten aufgezeigt:

* Eine Domain einrichten: [[Domainregistrierung]] 
* Eine Domain kündigen: [[Domainkündigung]] 
* Verwalten von Domains, Subdomains, Eigentümer, Nameserver: [[Domainverwaltung]] 

= Weiterführende Links =
{{Kerndoku|https://www.hostsharing.net/doc/managed-operations-platform/domain/}}
Was ist eine [[Domain]] 
Was ist ein [[Handles|Domainhandle]] 
[[FAQ#Domains|Einträge zu Domains in der HS FAQ]]

----
[[Kategorie:HSDoku]]
[[Kategorie:Domains]]

Domainregistrierung

2023-06-01T08:42:31Z

Edv38: aktueller Registrar

{{HSDoku-DomainLinks}}
__NOTOC__

=== Erst eine neue Domain über HSAdmin einrichten, dann über das Domain-Bestellsystem registrieren oder von einem anderen Provider transferieren ===

Wird eine neue Domain registriert oder von einem anderen Provider zu Hostsharing transferiert, sollte im Normalfall die Domain bei Hostsharing über HSAdmin eingerichtet werden, bevor die Registrierung letztlich eingeleitet bzw. aktualisiert wird. Sonst kann es zu Problemen beim Konnektieren der Domain kommen.

= Einrichten der Domain auf den HS Servern =

{{Kerndoku|https://doc.hostsharing.net/#kap-ref-domain}}

Der Domainname muss im Punicode Format angelegt werden aus münster.de wird xn--mnster-3ya.de .

Bei diesem Vorgang werden die Verzeichnisse für die Domain im eigenen Paket angelegt und die Domain wird auf die Mail, Web- und Nameserver von HS [[Aufschaltung|aufgeschaltet]]. Letzteres (das Nameserver-Update) ist Voraussetzung für den nächsten Schritt.

= Domainregistrierung oder eingehender Transfer ([[KK]]) =

== Bei fremdem Provider registrierte Domain zum Transfer freischalten ==

Falls die Domain bisher bei einem anderen Provider gehostet ist, muss diesem die Transfer-Absicht mitgeteilt werden. Dafür gibt es bei den jeweiligen Providern etablierte Verfahren, die dort zu erfragen sind. Üblicherweise bekommt man dort einen AuthCode für die Domain mitgeteilt. Gibt es kein etabliertes Verfahren, so kann man wie folgt verfahren:

* Formlos per Brief/Fax den Transfer ankündigen und um Zustimmung bitten, z.B.:
<pre>
Hiermit kündige ich als Owner/Admin-C den Transfer (KK) der
Domain example.com zur Hostsharing eG, vertreten durch den Registrar
RegistryGate GmbH, an. Ich bitte, dem folgenden Transferantrag zuzustimmen.
</pre>

* Nach Absendung der Transfer-Ankündigung 3-4 Tage warten, um dem alten Provider Zeit zu geben auf den Transferantrag zu reagieren.
* Wenn dem Transfer nicht stattgegeben wird, den Registrar der Domain herausfinden (z.B. über die Nameserver oder zuständige Registry) und bitten den Transfer zuzulassen.

== Neuregistrierung oder Transfer zu Hostsharing ([[KK]]) ==

Die Vorgehensweise ist unter https://doc.hostsharing.net/einstieg/domain.html beschrieben.

* Bei der allerersten Domainregistrierung im Domainbestellsystem müssen die Hostsharing Nameserver noch manuell eingegeben werden. Es sind dies:

dns1.hostsharing.net
dns2.hostsharing.net
dns3.hostsharing.net

= E-Mail-Adressen der neu eingerichteten Domain =

Ist die Domain bei Hostsharing aufgeschaltet, sind standardmäßig nur die E-Mail-Adressen webmaster@..., postmaster@... und abuse@... eingerichtet. Die Einrichtung weiterer E-Mail-Adressen ist unter https://doc.hostsharing.net/einstieg/email.html beschrieben.

[[Kategorie:HSDoku]]
[[Kategorie:Domains]]
[[Kategorie:Hsadmin]]

Mastodon bei Hostsharing

2022-11-04T08:08:40Z

Edv38: Kurzbeschreibung des Dienstes, und Link auf Alternative Pleroma

Mastodon ist ein verteilter Microblogging Dienst, der das ActivityPub-Protokoll verwendet.

Wenn man nur wenige Nutzer oder gar nur für sich selbst einen Einstiegspunkt ins "Fediverse" schaffen will, kann sich auch die Ressourcen-schonende Alternative [[Pleroma]] anbieten.

Diese Anleitung beschreibt, wie man Mastodon auf der Managed Hosting Plattform von Hostsharing installieren kann.

Hostsharing selbst nutzt die Hosting Plattform und betreibt zwei Mastodon Instanzen:
* https://geno.social
* https://hostsharing.coop

Der Autor dieser Seite betreibt:
* https://krefeld.life

{{Textkasten|gelb|Für Managed Server|Ein funktionierender Mastodon-Server erfordert mehrere laufende Server-Dienste. Für den Betrieb ist ein Managed Server sinnvoll.}}

== Vorbereitungen ==

Mit Hilfe von HSAdmin wird angelegt:
# Ein User als Service-User mit ''/bin/bash'' als Shell, zum Beispiel Beispiel: ''xyz00-mastodon''
# Eine Domain mit ''xyz00-mastodon'' als Domain-Administrator, zum Beispiel ''beispiel.social''
# Einen Postgresql-User ''xyz00_mastuser'' mit Passwort ''meinPasswort''
# Eine Postgresql-Datenbank ''xyz00_mastdb'' mit Datenbank-Owner ''xyz00_mastuser''

Verwendete IP-Ports der Server-Dienste:
# Monit: localhost:32001
# Redis: localhost:32002
# Mastodon-Web: localhost:32003
# Mastodon-Streaming: localhost:32004

== Konfiguration des Redis Server ==

Anlegen einer Datei ''/home/pacs/xyz00/users/mastodon/redis/etc/redis.conf'' mit folgendem Inhalt:

daemonize yes
pidfile /home/pacs/xyz00/users/mastodon/redis/var/redis-server.pid
requirepass <hierhin-gehoert-ein-redis-passwort>
port 32002
tcp-backlog 128
bind 127.0.0.1
timeout 300
loglevel notice
logfile /home/pacs/xyz00/users/mastodon/redis/var/redis.log
databases 16
save 900 1
save 300 10
save 60 10000
slave-serve-stale-data yes
appendonly no
dbfilename dump.rdb
dir /home/pacs/xyz00/users/mastodon/redis/var

== Installation von NodeJS ==

Als User 'xyz00-mastodon'': Installation von ''nvm'' und ''nodejs'' (Version 12) nach der Anleitung [[NodeJS]]

Installation von ''yarn'' mit:

npm install -g yarn

== Installation von Ruby ==

Als User ''xyz00-mastodon'': Installation von Ruby mit ''rbenv'' mit folgenden Befehlen:

Zunächst ''rbenv'' and ''ruby-build'':

git clone https://github.com/rbenv/rbenv.git ~/.rbenv
cd ~/.rbenv && src/configure && make -C src
echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.profile
echo 'eval "$(rbenv init -)"' >> ~/.profile

starte neue Shell:

exec bash

Überprüfe rbenv-Installation

type rbenv

Installiere ruby-build als rbenv-Plugin

git clone https://github.com/rbenv/ruby-build.git ~/.rbenv/plugins/ruby-build

Nun kann die benötigte Ruby-Version installiert werden:

rbenv install 2.7.2

== Installation der Mastodon Software ==

Weiterhin Als User ''xyz00-mastodon'':

cd ~
git clone https://github.com/tootsuite/mastodon.git live
cd ~/live

Die stabile Version auschecken:

git checkout $(git tag -l | grep -v 'rc[0-9]*$' | sort -V | tail -n 1)

Ruby Pakete installieren:

gem install bundler
bundle install -j$(getconf _NPROCESSORS_ONLN) --deployment --without development test

Node.js Pakete installieren:

yarn install --pure-lockfile

== Konfiguration der Mastodon Software ==

Anlegen einer Datei ''/home/pacs/xyz00/users/mastodon/live/.env.production'' mit dem folgenden Inhalt:

REDIS_HOST=localhost
REDIS_PORT=32002
REDIS_PASSWORD=<hierhin-gehoert-ein-redis-passwort>
DB_HOST=localhost
DB_USER=xyz00_mastuser
DB_NAME=xyz00_mastdb
DB_PASS=meinPasswort
DB_PORT=5432
LOCAL_DOMAIN=beispiel.social
SECRET_KEY_BASE=12ab..
OTP_SECRET=34ef..
VAPID_PRIVATE_KEY=ABCD..
VAPID_PUBLIC_KEY=EFGH..
DEFAULT_LOCALE=de
SMTP_SERVER=localhost
SMTP_PORT=25
SMTP_FROM_ADDRESS=notifications@beispiel.social
SMTP_AUTH_METHOD=none
SMTP_OPENSSL_VERIFY_MODE=none
STREAMING_CLUSTER_NUM=1

Die Zufallswerte für die Variablen SECRET_KEY_BASE und OTP_SECRET erzeugt man durch zwei Aufrufe des Kommandos

RAILS_ENV=production bundle exec rake secret

Die Werte für VAPID_PRIVATE_KEY und VAPID_PUBLIC_KEY erzeugt das Kommando

RAILS_ENV=production bundle exec rake mastodon:webpush:generate_vapid_key

Initialisieren der Datenbank:

export SAFETY_ASSURED=1
RAILS_ENV=production bundle exec rails db:schema:load
RAILS_ENV=production bundle exec rails db:seed

Erzeugen der Web-Resourcen

RAILS_ENV=production bundle exec rails assets:precompile

== Starten der Dienste ==

Zum Start aller notwendigen Dienste wird in dieser Anleitung ''monit'' benutzt. Hier ein Beispiel für eine Datei ''.monitrc'' (überlange Zeilen werden hier im Wiki umgebrochen)

set daemon 60
with start delay 120
set logfile /home/pacs/xyz00/users/mastodon/monit/var/monit.log
set idfile /home/pacs/xyz00/users/mastodon/monit/var/monit.id
set statefile /home/pacs/xyz00/users/mastodon/monit/var/monit.state
set mailserver localhost
set mail-format { from: monit@beispiel.social }
set alert mastodon@beispiel.social
set httpd port 32001 address xyz00.hostsharing.net
allow mostodon:monitpassword
check process redis with pidfile /home/pacs/xyz00/users/mastodon/redis/var/redis-server.pid
start program "/usr/bin/redis-server /home/pacs/xyz00/users/mastodon/redis/etc/redis.conf"
stop program "/bin/bash -c '/bin/kill $( cat /home/pacs/xyz00/users/mastodon/redis/var/redis-server.pid )'"
check process mstdn_web with pidfile /home/pacs/xyz00/users/mastodon/mastodon/var/puma.pid
depends redis
start program "/bin/bash -c 'export RAILS_ENV=production && export HOME=/home/pacs/xyz00/users/mastodon && cd $HOME/live && ( $HOME/.rbenv/shims/bundle exec puma -C config/puma.rb -e production -b tcp://127.0.0.1:32003 >$HOME/mastodon/var/puma.log 2>&1 & echo $! > $HOME/mastodon/var/puma.pid )'"
stop program "/bin/bash -c '/bin/kill $( cat /home/pacs/xyz00/users/mastodon/mastodon/var/puma.pid )'"
check process mstdn_sidekiq with pidfile /home/pacs/xyz00/users/mastodon/mastodon/var/sidekiq.pid
depends redis
start program "/bin/bash -c 'export RAILS_ENV=production && export DB_POOL=5 && export HOME=/home/pacs/xyz00/users/mastodon && cd $HOME/live && ( $HOME/.rbenv/shims/bundle exec sidekiq -c 5 -q default -q mailers -q pull -q push -q scheduler >$HOME/mastodon/var/sidekiq.log 2>&1 & echo $! > $HOME/mastodon/var/sidekiq.pid )'"
stop program "/bin/bash -c '/bin/kill $( cat /home/pacs/xyz00/users/mastodon/mastodon/var/sidekiq.pid )'"
check process mstdn_streaming with pidfile /home/pacs/xyz00/users/mastodon/mastodon/var/streaming.pid
depends redis
start program "/bin/bash -c 'export HOME=/home/pacs/xyz00/users/mastodon && export NVM_DIR="$HOME/.nvm" && export NVM_BIN=/home/pacs/xyz00/users/mastodon/.nvm/versions/node/v12.22.1/bin && export NODE_ENV=production && export PORT=32004 && export BIND=127.0.0.1 && cd $HOME/live && ( $HOME/.nvm/versions/node/v12.22.1/bin/node streaming/index.js >$HOME/mastodon/var/streaming.log 2>&1 & echo $! > $HOME/mastodon/var/streaming.pid )'"
stop program "/bin/bash -c '/bin/kill $( cat /home/pacs/xyz00/users/mastodon/mastodon/var/streaming.pid )'"

== Einrichten des Apache VHost ==

cd ~/doms/beispiel.social
rm -rf htdocs-ssl subs/www subs-ssl/www
ln -s ~/live/public htdocs-ssl
touch htdocs-ssl/.htaccess

Dann die ''htdocs-ssl/.htaccess'' mit dem Editor der Wahl öffnen und
folgende Konfiguration einfügen:

DirectoryIndex disabled
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_URI} ^/api/v1/streaming [NC]
RewriteRule .* ws://localhost:32004%{REQUEST_URI} [proxy]
RequestHeader set X-Forwarded-Proto "https"
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule .* http://localhost:32003%{REQUEST_URI} [proxy]
RequestHeader set X-Forwarded-Proto "https"

== Cronjobs ==

''Cron'' wird für zwei Aufgaben genutzt:
* Start von monit nach einem Server Reboot
* Aufräumen von alten Resourcen

Einrichten der crontab mit ''cronttab -e''

HOME=/home/pacs/xyz00/users/mastodon
MAILTO=mastodon@beispiel.social
RAILS_ENV=production
NUM_DAYS=31

@reboot /usr/bin/monit -c $HOME/.monitrc
18 4 * * * cd $HOME/live && $HOME/live/bin/tootctl media remove

== Volltextsuche ==

In der installierten Version gibt es noch keine Volltextsuche. Es kann lediglich nach Nutzerkennungen und Hastags gesucht werden. Für die Volltextsuche kann optional Elasticsearch installiert werden.

* [[Elasticsearch]] bei Hostsharing
* https://docs.joinmastodon.org/admin/optional/elasticsearch/

== Instanz einrichten ==
Nach der Installation kann man sich auf https://beispiel.social einen Benutzer einrichten.

Auf der Kommandozeile:

RAILS_ENV=production bin/tootctl accounts create \
alice \
--email alice@example.com \
--confirmed \
--role admin

Weitere Einrichtung sollte vorgenommen werden, z.B. eine Beschreibung der Instanz hinterlegen, siehe https://docs.joinmastodon.org/admin/setup/

== Mastodon Updates ==

siehe:
* https://github.com/tootsuite/mastodon/releases

(hier für das Update auf die Mastodon Version v2.8.0 mit Ruby 2.6.1)

=== Ruby ===

cd ~/.rbenv
git pull
cd ~/.rbenv/plugins/ruby-build
git pull
cd
rbenv install -l
rbenv install 2.6.1
rbenv global 2.6.1

=== Mastodon ===

cd ~/mastodon/live
git fetch
git checkout v2.8.0
gem update --system
bundle install
yarn install
RAILS_ENV=production bundle exec rails db:migrate
RAILS_ENV=production bundle exec rails assets:precompile

Restart Mastodon!

== Links ==

* [https://joinmastodon.org/ Offizielle Webseite von Mastodon]
* im Archiv: https://github.com/mastodon/documentation/blob/archive/Running-Mastodon/Production-guide.md
* aktuell: https://docs.joinmastodon.org/admin/install/
* https://krinetzki.de/2017/04/installation-von-mastodon-auf-debian-8-jessie/
* [https://github.com/tpokorra/Hostsharing-Ansible-Mastodon Ansible Playbook für Hostsharing]

[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]

Pleroma

2022-11-04T07:43:23Z

Edv38: mit Mastodon-Anleitung verlinkt und Absatz über Ressourcen hinzugefügt

= Pleroma =

Pleroma ist eine Server-Software für einen "Microblogging" Server. Die Funktionalität ist vergleichbar mit Twitter.

Im Gegensatz zu Twitter ist Pleroma aber kein abgeschlossener Dienst eines kommerziellen Anbieters sondern Pleroma nimmt an der "Federation", der Föderation, teil. Nachrichten können mit Personen ausgetauscht werden, die Ihr Profil auf anderen Pleroma-, [[Mastodon bei Hostsharing|Mastodon]]- oder auch Pixelfed-Instanzen haben.

Das Protokoll zum Nachrichtenaustausch ist ActivityPub.

Im Vergleich zu einer [[Mastodon bei Hostsharing|Mastodon-Instanz]] brauchen Pleroma-Instanzen wenig Ressourcen. Pleroma bietet sich auch für einzelne Nutzer an, die am "Fediverse" teilnehmen und ihre Daten selber hosten und verwalten wollen, statt einer existierenden Instanz beizutreten und die Datenverwaltung abzugeben -- ähnlich wie einen eigenen E-Mail-Server zu betreiben, statt existierende E-Mail-Dienste in Anspruch zu nehmen, auch wenn man nur einen einzigen E-Mail Account für die eigene Domain hat.

== Installation ==

Folge der Installationsanleitung für OTP Releases:

* https://docs-develop.pleroma.social/backend/installation/otp_en/

== Links ==

* https://pleroma.social/
* https://blog.soykaf.com/post/what-is-pleroma/
* https://fediverse.network/

Amazon SES

2021-02-24T07:53:24Z

Edv38: Amazon SES Beispiel mit zonefile angelegt

{{HSDoku-Links}}

Amazon SES steht für "'''Simple Email Service'''" und ist ein Teil der Amazon Cloud oder AWS ("Amazon Web Services").

Vom Versenden von Newslettern und hochvolumigen Massen-E-Mails ist auf den Hostsharing Servern abzuraten. Amazon SES ist ein erschwinglicher Dienst, um [[E-Mail|E-Mails]] an tausende von Empfängern zu verschicken. Man kann mit selbst gehosteter Software zur Verwaltung von Newslettern wie z.B. [https://sendy.co/ Sendy] die Auslieferung via Amazon SES einrichten. Die Software kann dabei auf den Hostsharing Rechnern betrieben werden und der eigentliche Versand verfolgt dann über Amazons Cloud-Dienst.

Damit Amazon SES die eigenen E-Mail-Adressen allerdings akzeptiert, muss man die Adresse erst verifizieren. Das läuft über TXT records. Wenn man in der [https://console.aws.amazon.com/ses/home SES Management Console] eine Domain einstellt, werden die Werte, die man dafür braucht, angezeigt.

Den TXT record kann man in der Zonefile der Domain ergänzen. Wenn man noch kein Zonefile hat, kann man eins anlegen, das nur den Amazon SES Eintrag ergänzt, ohne den Rest der Einstellungen zu beeinträchtigen.

=== Beispiel ===

Für die Domain 'example.de' ändere man dazu <code>~/doms/example.de/etc/pri.example.de</code> so ab, dass die Werte von Amazon SES in einer eigenen Zeile nach einem Import der Standardeinstellungen stehen:

<pre>
{DEFAULT_ZONEFILE}
_amazonses.example.de. IN TXT "123456789asdf123456789asdf123456789asdf12="
</pre>

Die Werte kopiert man nach Anlegen der Doaaus dem SES Wichtig ist dabei der Punkt (.) nach dem Schlüssel/der Domäne, und die Anführungsstriche um den Wert herum.

----
[[Kategorie:E-Mail]]

User-Arten

2020-11-11T18:01:24Z

Edv38: Kerndoku Link aktualisiert

{{Kerndoku|Der Inhalt ist der Hostsharing Dokumentation unter

https://doc.hostsharing.net/referenz/benutzer/index.html

zu finden.
}}

----
[[Kategorie:HSDoku]]
[[Kategorie:User]]

Verwalten der Zonendaten

2020-11-11T16:48:13Z

Edv38: aktualisierte Links zur Doku

{{Kerndoku|https://doc.hostsharing.net/referenz/zonefile/index.html}}

Das Zonenfile für eine Domain enthält die Konfiguration des Domain Name Service ([[DNS]]), d.h. der [[Nameserver]] der Domain. Es wird hinterlegt, welche Hostnamen innerhalb der Domain existieren und auf welche IP-Adressen diese zeigen. Außerdem wird hierüber auch gesteuert, an welches System Mails für die Domain geliefert werden sollen. Für einfache und unkomplizierte Änderungen bitte in [[Simple Zonefile Howto]] schauen.

{{Textkasten|rot|Achtung|Aufgrund der zentralen Bedeutung sollten Änderungen nur mit Vorsicht vorgenommen werden, da eine fehlerhafte Einstellung dazu führen kann, dass die Webseite nicht mehr im Internet abgerufen werden kann oder Mails verloren gehen!}}

== Aktives Zonefile ==

Die gerade aktive Konfiguration einer Domain example.com ist in /etc/bind/pri.example.com zu finden ([[Zonefile]]).

Im Standardfall sieht es vollständig expandiert wie folgt aus:

<pre><nowiki>example.com. IN SOA h00.hostsharing.net. hostmaster.hostsharing.net. (
1303649373 ; serial secs since Jan 1 1970
6H ; refresh (>=10000)
1H ; retry (>=1800)
1W ; expire
1H ; minimum
)

example.com. IN NS dns1.hostsharing.net.
example.com. IN NS dns2.hostsharing.net.
example.com. IN NS dns3.hostsharing.net.

example.com. IN MX 30 mailin1.hostsharing.net.
example.com. IN MX 30 mailin2.hostsharing.net.
example.com. IN MX 30 mailin3.hostsharing.net.

example.com. IN A 83.223.95.160
example.com. IN AAAA 2a01:37:1000::53df:5fa0:0

example.com. IN TXT "v=spf1 include:spf.hostsharing.net ?all"

*.example.com. IN MX 30 mailin1.hostsharing.net.
*.example.com. IN MX 30 mailin2.hostsharing.net.
*.example.com. IN MX 30 mailin3.hostsharing.net.

*.example.com. IN A 83.223.95.160
*.example.com. IN AAAA 2a01:37:1000::53df:5fa0:0

*.example.com. IN TXT "v=spf1 include:spf.hostsharing.net ?all"
</nowiki></pre>

== Logfile und Kontrolle==

Die Logfiles des Nameservers sind im Verzeichnis /var/log/named einsehbar. Das aktuelle Log wird unter dem Namen named.log angelegt. Dieses wird beim Neustart des DNS-Servers immer neu angelegt und zeigt bei einer erfolgreichen Änderung etwa folgenden Inhalt:

Oct 11 18:32:21.400 info: zone example.org/IN: loaded serial 1065889567
Oct 11 18:32:21.435 info: zone example.org/IN: sending notifies (serial 1065889567)
Oct 11 18:32:21.755 info: client 213.133.116.2#57100: transfer of 'example.org/IN':
AXFR-style IXFR started
Oct 11 18:32:22.264 info: client 62.75.149.27#45282: transfer of 'example.org/IN':
AXFR-style IXFR started

Die Zeilen bedeuten jeweils:

* Das geänderte Zonefile wurde vom DNS-Server erfolgreich geladen
* Der lokale Server sendet eine Benachrichtigung an die Secondaries, damit diese die Änderung ebenfalls übernehmen können.

Tippfehler oder falsche Angaben im Zonefile werden hier ebenfalls gemeldet.

<pre>
-------- Original-Nachricht --------
Betreff: [Global] DNS Zonenfile Änderungen
Datum: Thu, 4 Mar 2010 08:30:34 +0100

Moin Moin,

aus gegebenem Anlass: Immer wieder kommt es vor, dass jemand sein
Zonenfile ändert, und es (scheinbar) funktioniert. Tage oder Wochen
später dann sind die Domains nicht mehr erreichbar und es heißt "in den
letzten ... Tagen/Wochen habe ich aber gar nichts mehr geändert". Das mag
auch gut sein - ist mir auch selbst schon passiert, gerade wenn es um
"mal eben schnell noch ... " ging.

Nur ist der Fehler dann aber schon vor Tagen/Wochen passiert, und solange
die Datensätze nicht abgelaufen (expired) sind, sind sie - die alten -
noch im DNS System vorhanden. Die neuen aber, die aus der o.g. Änderung,
sind bei einem Fehler im Zonenfile nie ins DNS System hinein gekommen!

Was also tun? Zunächst kann man nach einer Änderung in einer
Shell beobachten, ob es zu Fehlermeldungen kommt:

tail -f /var/log/named/named.log

oder ggf nur Zeilen, in denen die eigene Domain (z.B. example.com)
vorkommt:

tail -f /var/log/named/named.log | grep example.com

Diese Log-Datei ist daher genau aus diese Grunde auch auf dem
Server lesbar.

Auch sollte die in den DNS-Servern befindliche Seriennummer mit der
aktuellen in der Zonendatei verglichen werden:

dig -t SOA @dns1 example.com | grep '^example.com.*SOA' | awk '{ print $7 }'

grep serial /etc/bind/pri.example.com | awk '{ print $1 }'
</pre>

== Eigenes Zonenfile ==

Wer ein eigenes Zonefile installieren möchte, um diverse Anwendungsfälle zu realisieren (Verweise auf extern gelagerte Subdomains, Anbindung externer Server, Verwendung eigener Mailserver), kann '''pro Domain''' ein eigenes Zonefile erstellen. Dieses befindet sich im Verzeichnis '''~/doms/example.com/etc''' mit den Namen '''pri.example.com''' (example.com steht hier als Beispiel für den wahren Domainnamen). Ein Neuanlegen oder eine Änderung dieser Datei führt zu einer baldigen Änderung der Nameservereinträge für die Domain.

{{Textkasten|rot|Warnung!|Das nicht sachgemäße Erstellen eines eigenen Zonefiles kann zur Nichterreichbarkeit der eigenen Domain und zum Verlust von Mails führen!}}

Eine Anleitung für die eher einfachen und oft gewünschten Änderungen findet sich in [[Simple Zonefile Howto]].

Folgende Platzhalter können und sollten in eigenen Zonenfiles verwendet werden. Sie ermöglichen uns das Ändern der DNS-Konfiguration, ohne dass der Domain-Admin sein Zonefile anpassen muss.

=== Komplexe Platzhalter ===

<pre>
{DEFAULT_ZONEFILE} :=
{HEADER}
{SOA_RR}
{NS_RR}
{MX_RR}
{A_RR}
{WILDCARD_MX_RR}
{WILDCARD_A_RR}

{HEADER} :=
$TTL {TTL}

{SOA_RR} :=
{DOM_HOSTNAME}. IN SOA {SOA_HOSTNAME}. {SOA_EMAIL}. (
{SIO} ; serial secs since Jan 1 1970
{REFRESH} ; refresh (>=10000)
{RETRY} ; retry (>=1800)
{EXPIRE} ; expire
{MINIMUM} ; minimum
)

{NS_RR} :=
{DOM_HOSTNAME}. IN NS {DNS1_HOSTNAME}.
{DOM_HOSTNAME}. IN NS {DNS2_HOSTNAME}.
{DOM_HOSTNAME}. IN NS {DNS3_HOSTNAME}.

{MX_RR} :=
{DOM_HOSTNAME}. IN MX 30 {MX1_HOSTNAME}.
{DOM_HOSTNAME}. IN MX 30 {MX2_HOSTNAME}.
{DOM_HOSTNAME}. IN MX 30 {MX3_HOSTNAME}.

{A_RR} :=
{DOM_HOSTNAME}. IN A {DOM_IPNUMBER}

{WILDCARD_MX_RR} :=
*.{DOM_HOSTNAME}. IN MX 30 {MX1_HOSTNAME}.
*.{DOM_HOSTNAME}. IN MX 30 {MX2_HOSTNAME}.
*.{DOM_HOSTNAME}. IN MX 30 {MX3_HOSTNAME}.

{WILDCARD_A_RR} :=
*.{DOM_HOSTNAME}. IN A {DOM_IPNUMBER}
</pre>

=== Atomare Platzhalter ===

<pre>
{TTL} := 6H
{SOA_HOSTNAME} := <HIVE>.hostsharing.net
{SOA_EMAIL}:= hostmaster.hostsharing.net
{SIO} := <SEKUNDEN>
{REFRESH} := 6H
{RETRY} := 1H
{EXPIRE} := 1W
{MINIMUM} := 1H

{DNS1_HOSTNAME} := dns1.hostsharing.net
{DNS2_HOSTNAME} := dns2.hostsharing.net
{DNS3_HOSTNAME} := dns3.hostsharing.net

{MX1_HOSTNAME} := mailin1.hostsharing.net
{MX2_HOSTNAME} := mailin2.hostsharing.net
{MX3_HOSTNAME} := mailin3.hostsharing.net

{DOM_HOSTNAME} := <FQDN>
{DOM_IPNUMBER} := <IP>
</pre>

Hierbei stehen
* <Sekunden> für die Anzahl der Sekunden, welche seit dem 01.01.1970 vergangen sind
* <FQDN> für den vollständigen, qualifizierten Domainnamen der Domain
* <IP> für die der Domain zugewiesene IP-Adresse

Diese Werte werden von Hostsharing verwaltet.

=== Expansion der Platzhalter ===

Der Platzhalter für das Gesamtzonefile {DEFAULT_ZONFILE} wird folgermaßen expandiert.

Zunächst werden die komplexen Platzhalter ersetzt:

<pre>
$TTL {TTL}

{DOM_HOSTNAME}. IN SOA {SOA_HOSTNAME}. {SOA_EMAIL}. (
{SIO} ; serial secs since Jan 1 1970
{REFRESH} ; refresh (>=10000)
{RETRY} ; retry (>=1800)
{EXPIRE} ; expire
{MINIMUM} ; minimum
)

{DOM_HOSTNAME}. IN NS {DNS1_HOSTNAME}.
{DOM_HOSTNAME}. IN NS {DNS2_HOSTNAME}.
{DOM_HOSTNAME}. IN NS {DNS3_HOSTNAME}.

{DOM_HOSTNAME}. IN MX 30 {MX1_HOSTNAME}.
{DOM_HOSTNAME}. IN MX 30 {MX2_HOSTNAME}.
{DOM_HOSTNAME}. IN MX 30 {MX3_HOSTNAME}.

{DOM_HOSTNAME}. IN A {DOM_IPNUMBER}

*.{DOM_HOSTNAME}. IN MX 30 {MX1_HOSTNAME}.
*.{DOM_HOSTNAME}. IN MX 30 {MX2_HOSTNAME}.
*.{DOM_HOSTNAME}. IN MX 30 {MX3_HOSTNAME}.

*.{DOM_HOSTNAME}. IN A {DOM_IPNUMBER}
</pre>

Anschließend werden die atomaren Platzhalter ersetzt:

<pre>
$TTL 6H

<FQDN>. IN SOA <HIVE>.hostsharing.net. hostmaster.hostsharing.net. (
<SEKUNDEN> ; serial secs since Jan 1 1970
6H ; refresh (>=10000)
1H ; retry (>=1800)
1W ; expire
1H ; minimum
)

<FQDN>. IN NS dns1.hostsharing.net.
<FQDN>. IN NS dns2.hostsharing.net.
<FQDN>. IN NS dns3.hostsharing.net.

<FQDN>. IN MX 30 mail1.hostsharing.net.
<FQDN>. IN MX 30 mail2.hostsharing.net.
<FQDN>. IN MX 30 mail3.hostsharing.net.

<FQDN>. IN A <IP>

*.<FQDN>. IN MX 30 mail1.hostsharing.net.
*.<FQDN>. IN MX 30 mail2.hostsharing.net.
*.<FQDN>. IN MX 30 mail3.hostsharing.net.

*.<FQDN>. IN A <IP>
</pre>

== Das Zonefile deaktivieren/zurücksetzen ==

In ~/doms/example.com/etc das vorhandene Zonefile (pri.example.com) komplett leeren (ist dann 0 Bytes groß). Dann kommt der Robot vorbei, löscht pri.example.com und setzt alles auf Standardwerte zurück.

----
[[Kategorie:HSDoku]]
[[Kategorie:Domains]]
[[Kategorie:Zonefile]]
[[Kategorie:DNS]]

Nameserver

2020-11-11T16:46:54Z

Edv38: aktualisierte Links zur Doku

Für Domains, die bei Hostsharing registriert sind, gibt es drei redundante Nameserver, die auf Anfrage die Zuordnung Domainname (z.B. www.example.com) -> IP-Adresse (z.B. 1.2.3.4) vornehmen. Diese Nameserver stehen aus Gründen der Zuverlässigkeit und Ausfallsicherheit in drei verschiedenen [https://de.wikipedia.org/wiki/Autonomes_System autonomen Systemen] an verschiedenen Standorten. Die Namen dieser Nameserver lauten:

* dns1.hostsharing.net
* dns2.hostsharing.net
* dns3.hostsharing.net

Jede Nutzung eines Dienstes (z.B. E-Mail, WWW, FTP, SSH und viele andere) im Internet, die über den Domainnamen des zugehörigen Rechners erfolgt, benötigt einen Nameserver, der die Frage nach der IP-Adresse des Rechners beantwortet.

Ohne Nameserver kann der Dienst natürlich auch erreicht werden, und zwar direkt über seine IP-Adresse. Aber nur die Existenz des Nameservers erlaubt es, den Dienst über seinen Domainnamen aufzurufen.

===Häufige Frage===
Manchmal werden im Domainbestellsystem Einträge für secondary Domainserver nicht angenommen. Das könnte daran liegen, dass die nötigen Schritte nicht in der nötigen Reihenfolge abgearbeitet wurden.

Anleitung: [https://doc.hostsharing.net/einstieg/domain.html Domain bestellen]

== Siehe auch ==
[[Verwalten der Zonendaten]]

[[Kategorie:HSDoku]]
[[Kategorie:Zonefile]]
[[Kategorie:DNS]]
[[Kategorie:Domains]]
[[Kategorie:Glossar]]

Nextcloud

2020-07-05T10:01:27Z

Edv38: eigenen Abschnitt zu allgemeinen Infos vorgeschaltet

= Nextcloud =

[https://nextcloud.com/ Nextcloud] ist eine PHP-basierte Open Source Lösung für gängige Cloud-Anwendungen, u.a.:

* File sharing unter Nutzern derselben Nextcloud, und mit der Öffentlichkeit
* Single-Sign-On Authentifizierung (SSO)
* Videokonferenzen (WebRTC)
* Online-Office Anwendung [https://www.collaboraoffice.com/ Collabora Online]

Beispiel-Funktionalität, die über Plugins, sogenannte [https://apps.nextcloud.com/ "Apps"], bereit gestellt werden kann:

* Kalender, Aufgabenverwaltung, Adressbudd
* Datei-Kollaboration (Kommentare zu Dateien, Verschlagwortung)
* Feedreader
* E-Mail-Programm
* Fotogalerie
* Musik- und Videowiedergabe

= Nextcloud installieren =

== Vorbereitungen ==

In ''hsadmin'', zum Beispiel mit ''hsscript'':

''hsadmin''-Shell starten mit:

hsscript -u xyz00 -i
Password: ********

Dann nacheinander anlegen:

* Linux User als Domain-Administrator
* Subdomain ''cloud.example.org''
* PostgreSQL-User
* PostgreSQL Datenbank

xyz00@hsadmin> user.add({set:{name:'xyz00-cloud',password:'geheim',shell:'/bin/bash',comment:'Nextcloud'}})
xyz00@hsadmin> domain.add({set:{name:'cloud.example.org',user:'xyz00-cloud'}})
xyz00@hsadmin> postgresqluser.add({set:{name:'xyz00_nextclusr',password:'geheim'}})
xyz00@hsadmin> postgresqldb.add({set:{name:'xyz00_nextcloud',owner:'xyz00_nextclusr'}})

== Nextcloud installieren ==

Anmelden als Linux-User ''xyz00-cloud'':

ssh -l xyz00-cloud xyz00.hostsharing.net

''htdocs'' Verzeichnis vorbereiten

cd
mkdir nextcloud
cd doms/cloud.example.org
rm -rf subs/www subs-ssl/www htdocs-ssl
ln -s $HOME/nextcloud htdocs-ssl

Nextcloud herunterladen und entpacken.

cd
wget https://download.nextcloud.com/server/releases/nextcloud-16.0.4.zip
unzip nextcloud-16.0.4.zip
rm nextcloud-16.0.4.zip
mkdir data tmp
chmod 700 data tmp

== Nextcloud konfigurieren ==

Zur Zeit muss für Nextcloud PHP in der Version 7.3 manuell aktiviert werden. Eine Anleitung dazu findet sich auf der Seite [[PHP#Vorinstallierte_PHP_Version_wechseln]]

Im Verzeichnis "$HOME/doms/cloud.example.org/fastcgi-ssl/" eine Datei "php.ini" anlegen mit folgendem Inhalt:

memory_limit=512M
session.save_path=/home/pacs/xyz00/users/cloud/tmp
opcache.enable=1
opcache.enable_cli=1
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000
opcache.memory_consumption=128
opcache.save_comments=1
opcache.revalidate_freq=1

Dann mit einem Editor diese Datei bearbeiten: In der erste Zeile den korrekten Pfad des vorher angelegten tmp-Verzeichnisses eintragen.

Im Browser auf die Seite
http://cloud.example.org gehen und den Anweisungen folgen.

Auf der ersten Seite sind anzugeben:

* Login und Passwort für den Administrator definieren
* PostgreSQL als Datenbanksystem
* PostgreSQL-User und Passwort aus dem ersten Schritt oben
* Name der PostgreSQL-Datenbank aus dem ersten Schritt
* "localhost" als Datenbankserver
* Das Verzeichnis "/home/pacs/xyz00/users/cloud/data/" als Daten-Verzeichnis

== Nextcloud beschleunigen ==

Dieser Teil ist optional.

Wenn regelmäßig '''im Browser''' mit Nextcloud gearbeitet werden soll, ist Nextcloud im Browser oft sehr langsam. Um dies zu verbessern unterstützt Nextcloud die Anwendung von unterschiedlichen Cache-Verfahren (zum Beispiel Memcache, Redis).

Redis ist auf den Hostsharing-Servern vorinstalliert und wird von den Nextcloud-Entwicklern empfohlen. '''In Verbindung mit einem Managed Webspace''' muss Redis als eigener Server '''Daemon''' angemeldet werden und ist '''kostenpflichtig'''. Siehe zu Kosten im Webspace Konfigurator unter: https://www.hostsharing.net/angebote/managed-webspace/ – '''1 individueller Serverdienst''' (Daemons).

Mit dem Hostsharing-Service wird ein IP-Port für die Nutzung von Redis vereinbart.

Für den Redis-Dienst lege ich folgende Struktur an:

cd ~
mkdir -p ~/redis/etc
mkdir -p ~/redis/var

In ''~/redis/etc'' lege ich eine Konfigurationsdatei ''redis.conf'' für den Redis-Dienst ab:

daemonize yes
pidfile /home/pacs/xyz00/users/cloud/redis/var/redis-server.pid
requirepass mein-redis-passwort
port 32123
tcp-backlog 128
bind 127.0.0.1
timeout 300
loglevel notice
logfile /home/pacs/xyz00/users/cloud/redis/var/redis.log
databases 16
save 900 1
save 300 10
save 60 10000
slave-serve-stale-data yes
appendonly no
dbfilename dump.rdb
dir /home/pacs/xyz00/users/cloud/redis/var

Den Start und das Monitoring des Redis-Dienstes übernimmet ''monit''. Hier eine geeignete Datei ''~/.monitrc'':

set daemon 60
with start delay 120
set logfile /home/pacs/xyz00/users/cloud/monit/var/monit.log
set idfile /home/pacs/xyz00/users/cloud/monit/var/monit.id
set statefile /home/pacs/xyz00/users/cloud/monit/var/monit.state
set mailserver localhost
set mail-format { from: monit@cloud.example.com }
set alert webmaster@example.com
set httpd port 32123 address xyz00.hostsharing.net
allow nextcloud:mein-monit-passwort
check process redis with pidfile /home/pacs/xyz00/users/cloud/redis/var/redis-server.pid
start program "/usr/bin/redis-server /home/pacs/xyz00/users/cloud/redis/etc/redis.conf"
stop program "/bin/bash -c '/bin/kill $( cat /home/pacs/xyz00/users/cloud/redis/var/redis-server.pid )'"

Zugriffsrechte für die Datei ''~/.monitrc'' setzen:

cd ~
chmod 600 .monitrc

Verzeichnis für ''monit'' anlgegen:

cd ~
mkdir -p monit/var

In der Konfiguration der Nextcloud (in ''~/nextcloud/config/config.php'') wird der Redis-Cache wie folgt konfiguriert:

'memcache.local' => '\\OC\\Memcache\\Redis',
'memcache.distributed' => '\\OC\\Memcache\\Redis',
'memcache.locking' => '\\OC\\Memcache\\Redis',
'redis' =>
array (
'host' => '127.0.0.1',
'port' => 32123,
'password' => 'mein-redis-passwort',
'timeout' => 1.5,
),

Um es perfekt zu machen nutze ich ''logrotate'' um die Logdateien zu organisieren. Dazu die Konfiguration in ''~/.logrotate''

compress
/home/pacs/xyz00/users/cloud/redis/var/redis.log {
rotate 5
daily
missingok
}
/home/pacs/xyz00/users/cloud/monit/var/monit.log {
rotate 2
weekly
missingok
}

Eine Crontab sorgt für den Start von Monit und das tägliche Rotieren der Logdateien:

# m h dom mon dow command
HOME=/home/pacs/xyz00/users/cloud
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
MAILTO=webmaster@example.com
@reboot /usr/bin/monit -c $HOME/.monitrc
1 1 * * * /usr/sbin/logrotate -s $HOME/.logrotate.state $HOME/.logrotate
1,16,31,46 * * * * /usr/bin/php7.3 $HOME/nextcloud/cron.php

Die letzte Zeile der ''crontab'' enthält den Cronjob für die regelmäßigen Hintergrundprozesse der Nextcloud. Durch die Erledigung dieser Aufgaben mit Cron lässt sich die Nextcloud ebenfalls etwas beschleunigen.

== Nextcloud mit Online Office ==

In Nextcloud können Office-Dokumente (Textverarbeitung, Tabellen und Präsentationen) im Browser bearbeitet werden. Dazu steht bei Hostsharing die Collabora Developer Version zur Verfügung. Bestellung und Konfiguration sind hier im Wiki auf der Seite [[Collabora_Online]] beschrieben.

== Nextcloud mit Nextcloud Talk ==

Über die Nextcloud-App "Talk" können Videokonfererenzen mit Screensharing durchgeführt werden. Für die regelmäßige Nutzung kann es sinnvoll sein einen eigenen TURN Server zu betreiben. Siehe dazu [[Coturn_Installieren]]

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:CalDAV]]

Nextcloud

2020-07-05T10:00:07Z

Edv38: Nextcloud kurz zusammengefasst

= Nextcloud installieren =

[https://nextcloud.com/ Nextcloud] ist eine PHP-basierte Open Source Lösung für gängige Cloud-Anwendungen, u.a.:

- File sharing unter Nutzern derselben Nextcloud, und mit der Öffentlichkeit
- Single-Sign-On Authentifizierung (SSO)
- Videokonferenzen (WebRTC)
- Online-Office Anwendung [https://www.collaboraoffice.com/ Collabora Online]

Beispiel-Funktionalität, die über Plugins, sogenannte [https://apps.nextcloud.com/ "Apps"], bereit gestellt werden kann:

- Kalender, Aufgabenverwaltung, Adressbudd
- Datei-Kollaboration (Kommentare zu Dateien, Verschlagwortung)
- Feedreader
- E-Mail-Programm
- Fotogalerie
- Musik- und Videowiedergabe

== Vorbereitungen ==

In ''hsadmin'', zum Beispiel mit ''hsscript'':

''hsadmin''-Shell starten mit:

hsscript -u xyz00 -i
Password: ********

Dann nacheinander anlegen:

* Linux User als Domain-Administrator
* Subdomain ''cloud.example.org''
* PostgreSQL-User
* PostgreSQL Datenbank

xyz00@hsadmin> user.add({set:{name:'xyz00-cloud',password:'geheim',shell:'/bin/bash',comment:'Nextcloud'}})
xyz00@hsadmin> domain.add({set:{name:'cloud.example.org',user:'xyz00-cloud'}})
xyz00@hsadmin> postgresqluser.add({set:{name:'xyz00_nextclusr',password:'geheim'}})
xyz00@hsadmin> postgresqldb.add({set:{name:'xyz00_nextcloud',owner:'xyz00_nextclusr'}})

== Nextcloud installieren ==

Anmelden als Linux-User ''xyz00-cloud'':

ssh -l xyz00-cloud xyz00.hostsharing.net

''htdocs'' Verzeichnis vorbereiten

cd
mkdir nextcloud
cd doms/cloud.example.org
rm -rf subs/www subs-ssl/www htdocs-ssl
ln -s $HOME/nextcloud htdocs-ssl

Nextcloud herunterladen und entpacken.

cd
wget https://download.nextcloud.com/server/releases/nextcloud-16.0.4.zip
unzip nextcloud-16.0.4.zip
rm nextcloud-16.0.4.zip
mkdir data tmp
chmod 700 data tmp

== Nextcloud konfigurieren ==

Zur Zeit muss für Nextcloud PHP in der Version 7.3 manuell aktiviert werden. Eine Anleitung dazu findet sich auf der Seite [[PHP#Vorinstallierte_PHP_Version_wechseln]]

Im Verzeichnis "$HOME/doms/cloud.example.org/fastcgi-ssl/" eine Datei "php.ini" anlegen mit folgendem Inhalt:

memory_limit=512M
session.save_path=/home/pacs/xyz00/users/cloud/tmp
opcache.enable=1
opcache.enable_cli=1
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000
opcache.memory_consumption=128
opcache.save_comments=1
opcache.revalidate_freq=1

Dann mit einem Editor diese Datei bearbeiten: In der erste Zeile den korrekten Pfad des vorher angelegten tmp-Verzeichnisses eintragen.

Im Browser auf die Seite
http://cloud.example.org gehen und den Anweisungen folgen.

Auf der ersten Seite sind anzugeben:

* Login und Passwort für den Administrator definieren
* PostgreSQL als Datenbanksystem
* PostgreSQL-User und Passwort aus dem ersten Schritt oben
* Name der PostgreSQL-Datenbank aus dem ersten Schritt
* "localhost" als Datenbankserver
* Das Verzeichnis "/home/pacs/xyz00/users/cloud/data/" als Daten-Verzeichnis

== Nextcloud beschleunigen ==

Dieser Teil ist optional.

Wenn regelmäßig '''im Browser''' mit Nextcloud gearbeitet werden soll, ist Nextcloud im Browser oft sehr langsam. Um dies zu verbessern unterstützt Nextcloud die Anwendung von unterschiedlichen Cache-Verfahren (zum Beispiel Memcache, Redis).

Redis ist auf den Hostsharing-Servern vorinstalliert und wird von den Nextcloud-Entwicklern empfohlen. '''In Verbindung mit einem Managed Webspace''' muss Redis als eigener Server '''Daemon''' angemeldet werden und ist '''kostenpflichtig'''. Siehe zu Kosten im Webspace Konfigurator unter: https://www.hostsharing.net/angebote/managed-webspace/ – '''1 individueller Serverdienst''' (Daemons).

Mit dem Hostsharing-Service wird ein IP-Port für die Nutzung von Redis vereinbart.

Für den Redis-Dienst lege ich folgende Struktur an:

cd ~
mkdir -p ~/redis/etc
mkdir -p ~/redis/var

In ''~/redis/etc'' lege ich eine Konfigurationsdatei ''redis.conf'' für den Redis-Dienst ab:

daemonize yes
pidfile /home/pacs/xyz00/users/cloud/redis/var/redis-server.pid
requirepass mein-redis-passwort
port 32123
tcp-backlog 128
bind 127.0.0.1
timeout 300
loglevel notice
logfile /home/pacs/xyz00/users/cloud/redis/var/redis.log
databases 16
save 900 1
save 300 10
save 60 10000
slave-serve-stale-data yes
appendonly no
dbfilename dump.rdb
dir /home/pacs/xyz00/users/cloud/redis/var

Den Start und das Monitoring des Redis-Dienstes übernimmet ''monit''. Hier eine geeignete Datei ''~/.monitrc'':

set daemon 60
with start delay 120
set logfile /home/pacs/xyz00/users/cloud/monit/var/monit.log
set idfile /home/pacs/xyz00/users/cloud/monit/var/monit.id
set statefile /home/pacs/xyz00/users/cloud/monit/var/monit.state
set mailserver localhost
set mail-format { from: monit@cloud.example.com }
set alert webmaster@example.com
set httpd port 32123 address xyz00.hostsharing.net
allow nextcloud:mein-monit-passwort
check process redis with pidfile /home/pacs/xyz00/users/cloud/redis/var/redis-server.pid
start program "/usr/bin/redis-server /home/pacs/xyz00/users/cloud/redis/etc/redis.conf"
stop program "/bin/bash -c '/bin/kill $( cat /home/pacs/xyz00/users/cloud/redis/var/redis-server.pid )'"

Zugriffsrechte für die Datei ''~/.monitrc'' setzen:

cd ~
chmod 600 .monitrc

Verzeichnis für ''monit'' anlgegen:

cd ~
mkdir -p monit/var

In der Konfiguration der Nextcloud (in ''~/nextcloud/config/config.php'') wird der Redis-Cache wie folgt konfiguriert:

'memcache.local' => '\\OC\\Memcache\\Redis',
'memcache.distributed' => '\\OC\\Memcache\\Redis',
'memcache.locking' => '\\OC\\Memcache\\Redis',
'redis' =>
array (
'host' => '127.0.0.1',
'port' => 32123,
'password' => 'mein-redis-passwort',
'timeout' => 1.5,
),

Um es perfekt zu machen nutze ich ''logrotate'' um die Logdateien zu organisieren. Dazu die Konfiguration in ''~/.logrotate''

compress
/home/pacs/xyz00/users/cloud/redis/var/redis.log {
rotate 5
daily
missingok
}
/home/pacs/xyz00/users/cloud/monit/var/monit.log {
rotate 2
weekly
missingok
}

Eine Crontab sorgt für den Start von Monit und das tägliche Rotieren der Logdateien:

# m h dom mon dow command
HOME=/home/pacs/xyz00/users/cloud
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
MAILTO=webmaster@example.com
@reboot /usr/bin/monit -c $HOME/.monitrc
1 1 * * * /usr/sbin/logrotate -s $HOME/.logrotate.state $HOME/.logrotate
1,16,31,46 * * * * /usr/bin/php7.3 $HOME/nextcloud/cron.php

Die letzte Zeile der ''crontab'' enthält den Cronjob für die regelmäßigen Hintergrundprozesse der Nextcloud. Durch die Erledigung dieser Aufgaben mit Cron lässt sich die Nextcloud ebenfalls etwas beschleunigen.

== Nextcloud mit Online Office ==

In Nextcloud können Office-Dokumente (Textverarbeitung, Tabellen und Präsentationen) im Browser bearbeitet werden. Dazu steht bei Hostsharing die Collabora Developer Version zur Verfügung. Bestellung und Konfiguration sind hier im Wiki auf der Seite [[Collabora_Online]] beschrieben.

== Nextcloud mit Nextcloud Talk ==

Über die Nextcloud-App "Talk" können Videokonfererenzen mit Screensharing durchgeführt werden. Für die regelmäßige Nutzung kann es sinnvoll sein einen eigenen TURN Server zu betreiben. Siehe dazu [[Coturn_Installieren]]

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:CalDAV]]

Speicherbelegung

2020-05-02T08:48:56Z

Edv38: Ausführung wie man soft quota/hard quota abliest

== Paketspeicher ==

Der im gesamten Paket zur Verfügung stehende Speicher kann wie folgt abgefragt werden:

Einloggen als Paketadmin und '''quota -g''' eingeben (wir nutzen Gruppenquota). Die Felder bedeuten:

{| class="wikitable" style="margin: 0em 0em 0em 2em; font-size:1em;"
|- style="background-color:orange;"
!Feld !! Bedeutung
|- style="background-color:#CAE1FF;"
|blocks || KB belegt
|- style="background-color:#B9D3EE;"
|quota || normales (gebuchtes) Limit in KB; "soft quota"
|- style="background-color:#CAE1FF;"
|limit || maximales (temporär toleriertes) Limit in KB; "hard quota"
|- style="background-color:#B9D3EE;"
|grace || Anzahl der Tage, die man noch über "quota" bleiben darf (ist nur gesetzt, wenn blocks>quota)
|- style="background-color:#CAE1FF;"
|files ||Anzahl der INodes (entspricht nicht immer, aber fast einem File. Lediglich Hardlinks verbrauchen nur einen INode pro "realer" Datei)
|- style="background-color:#B9D3EE;"
|quota ||normales Limit der INode-Anzahl
|- style="background-color:#CAE1FF;"
|limit ||maximales Limit der INode-Anzahl
|- style="background-color:#B9D3EE;"
|grace || Anzahl der Tage, die man noch über "INode-quota" bleiben darf (ist nur gesetzt, wenn quota überschritten ist)
|-
|}

Um zu prüfen, ob ein Paket die Quota bald erreicht oder schon überschritten hat, muss man '''blocks''' mit '''quota''' in Verhältnis setzen. Wenn '''blocks > quota''', beginnt die ''grace period'', während der ein weiterer Anstieg des Speicherverbrauchs noch toleriert wird. In jedem Fall gilt '''blocks < limit''': die "hard quota" kann nicht überschritten werden und liegt z.B. bei 150% der "soft quota".

Der genutzte Speicher für den Paketadmin selbst kann mit '''du''' abgefragt werden: Einloggen als Paket-Admin und '''du -h''' eingeben. Der Befehl listet die aktuellen Größen der einzelnen Verzeichnisse auf und am Ende den gesamt belegten Plattenplatz in MB.

{{Textkasten|gruen||'''Achtung:''' Die Auflistung (mit '''du''') erfolgt ohne den Speicherplatz der User, für deren Verzeichnisse der Paketadmin kein Zugriffsrecht hat, ohne Dateien in /tmp/ und ohne Datenbanken!}}

Will man eine Übersicht über die Speicherbelegung aller User im Paket, verwendet man den Hostsharing-eigenen Befehl '''du-pac'''.

Von unserem Mitglied Andreas Loesch gibt es dazu außerdem das hervorragende Skript pac-du-quota, das die Plattennutzung oder die Gruppenquota aller User eines Hostsharing-Paketes auflistet: http://hs.andreasloesch.de/pac-du-quota

----
[[Kategorie:Pakete bei HS]]
[[Kategorie:HSDoku]]

PHP

2019-04-15T14:25:45Z

Edv38: Anleitung Wechsel auf PHP 7.3

PHP wird heute bei HS standardmäßig per FastCGI vorkonfiguriert. Dafür wird in jedem Domainverzeichnis unter fastcgi/ eine phpstub Datei angelegt und der Apache Webserver ist konfiguriert .php Dateien über diesen "Stub" mit den Rechten des Users auszuführen.

Zur Wiederherstellung des originalen phpstub ist dieser zentral abgelegt als

/usr/local/src/phpstub

Anwender, die lediglich PHP-Dateien hochgeladen haben, brauchen ausdrücklich keine eigene php.ini.

=== Anpassung der PHP Grundkonfiguration ===

Um die PHP Konfiguration an eigene Bedürfnisse anzupassen, legt man eine Konfigurationsdatei Namens php.ini im fastcgi Verzeichnis der Domain an (Für https:// entsprechend im -ssl Verzeichnis). In dieser Datei müssen nicht alle Konfigurationsoptionen von PHP definiert sein, sondern nur die, die sich gegenüber der Standard php.ini ändern sollen. Diese liegt in /etc/php/VERSION/cgi und kann dort eingesehen werden.

'''Achtung:''' Kommentare nicht mit # einleiten (kann zu unerwarteten Fehlkonfigurationen führen), Kommentarzeichen ist das Semikolon ";".

Häufig anzupassen sind z.B.:

* die Content-Type charset= Vorgabe für den HTTP Header.

* der maximal verwendbare Hauptspeicher (memory_limit).

* die maximale Größe hochgeladener Dateien (post_max_size).

* die aktiven Extensions.

Beispiel einer php.ini:

<pre>
------8< SCHNIPP >8------
[..]
memory_limit = 128M (default)
post_max_size = 8M (default)
upload_max_filesize = 2M (default)

[..]
default_charset = "UTF-8"
; (ist sonst iso-8859-1)
; Der charset kann aber wiederum durch einen Funktionsaufruf
; header("Content-Type: text/html; charset=iso-8859-1")
; im PHP-Skript überschrieben werden (sofern output_buffering = On).
------8< SCHNIPP >8------
</pre>

'''Beachte:''' Eine geänderte php.ini Konfiguration wird mit FastCGI erst übernommen, wenn die PHP Prozesse des Users (die über längere Zeit laufen bleiben) neu gestartet werden.

Die Brechstange, mit der das Neustarten der PHP Prozesse erzwungen werden kann, ist diese zu killen:
<pre>
killall php -u $USER
</pre>
$USER = ist der aktuell angemeldeten Benutzer und muss nicht durch den Benutzernamen (xyz00 oder xyz00-user) ersetzt werden. Nur die Prozesse der $USER werden gelöscht.

=== PHP Sicherheit ===

==== open_basedir ====

Sofern der PHP Parameter open_basdir nicht gesetzt ist (Vorgabe) können (kompromittierte) php Skripte an alle Dateien kommen des Users kommen, ohne einen extra Shellzugang installieren zu müssen und dadurch entdeckt zu werden.

Die Passwortabfrage von Hsadmin bringt eine Abhilfe für die zentralen Dienste. (Sofern Du dein Passwort nicht in eine Datei schreibst und die Abfrage so wieder ausschaltest, wovon besser abzusehen ist.) Doch alle Daten auf die Du als Benutzer zugreifen kannst sind prinzipiell den PHP-Skripten ausgeliefert.

Mit open_basedir wird festgelegt in welchen Verzeichnissen PHP Skripte lesen und schreiben dürfen. Geprüft wird dabei ob der zu öffnende Pfad mit dem angegebene Pfad beginnt. Es ist daher wichtig ob sich am Ende ein "/" befindet oder nicht. Ein open_basedir von /home/doms/example.org/subs/www (ohne /) erlaubt somit z.B. auch Zugriffe auf die Subdomain www2 etc.

Beispielzeile für die php.ini:
open_basedir = /home/doms/example.org/subs/

Wenn man mehrere Subdomains hat und diese isolieren möchte, ist dies durch Aufschaltung von lokalen Subdomains auf verschiedene User möglich. (Siehe https://doc.hostsharing.net/users/administration/domain/index.html )

==== safe_mode ====
{{Textkasten|rot|Veraltete Option|Die Verwendung des Safe Mode wird explizit '''nicht''' empfohlen. Mit PHP 5.3.0 ist der Safe Mode veraltet, in PHP 6 gibt es diese Option nicht mehr.}}

Dank (Fast)CGI laufen PHP Skripte zwar "nur" mit Userrechten, dennoch ist es ratsam, den PHP safe_mode zu aktivieren, sofern dies mit den eingesetzten PHP Skripten möglich ist. Der safe_mode kann auch die Daten des Users vor (kompromittierten) PHP Skripten schützen. In der php.ini ist dafür die Option

safe_mode = On

zu setzten, und die weiteren Optionen sind zu prüfen.

Falls Systembefehle oder Shellskripte ausgeführt werden müssen, sollten diese über ein extra safe_mode_exec_dir außerhalb des open_basedir bereitgestellt werden (z.B. ~/priv/bin).

==== Sicherheitskritische Funktionen ====

Weitere Dinge die deaktiviert werden sollten, wenn sie nicht benötigt werden, was im allgemeinen der Fall ist, sind: Das öffnen von URLs als Dateien,

allow_url_fopen = Off

und die Ausführung von Systembefehlen.

disable_functions = show_source, system, passthru, shell_exec, exec, phpinfo, popen, proc_open

=== eigene PHP Konfigurationen und verschiedene nebeneinander verwenden ===

Um verschiedene PHP Konfigurationen nebeneinander zu verwenden, kopierst Du den phpstub in ein Unterzeichnis von (fast)cgi(-ssl) und mappst (Einträge in der .htaccess) nach Belieben deine PHP Dateien darauf.
So können beliebig viele Konfigurationen bei einer Domain nebeneinander genutzt werden.

==== Beispiel muster.example.com ====
<pre>
mkdir ~/doms/example.com/fastcgi/muster
cp ~/doms/example.com/fastcgi/phpstub ~/doms/example.com/fastcgi/muster/phpstub

und wenn benötigt:
vi ~/doms/example.com/fastcgi/muster/php.ini
</pre>

Anschließend muss der Apache Webserver noch angewiesen werden auch diese bestimmte Konfiguration von PHP zu verwenden. Dazu werden der [[.htaccess]] Datei im DocumentRoot der Sub-Domain zwei Zeilen hinzugefügt bzw. eine .htaccess mit den zwei Zeilen angelegt.
Im Beispiel handelt es sich um die Domain muster.example.com, also:

<pre>
cd ~/doms/example.com/subs/muster
vi .htaccess

AddType application/x-httpd-phpfastcgi .php
Action application/x-httpd-phpfastcgi /fastcgi-bin/muster/phpstub
</pre>

== Vorinstallierte PHP Version wechseln ==
Hostsharing bietet neben der aktuellen (2019-04-15) Standardversion 7.0.x auch PHP 7.1, 7.2, und 7.3 an.

Um die Version zu wechseln, genügt es, den jeweiligen phpstub auszutauschen. Version 7.3 liegt unter <code>/usr/local/src/phpstub/phpstub73</code>; das Versionformat ist entsprechend <code>/usr/local/src/phpstub/phpstubXX</code>.

===phpstub für PHP 7.3 kopieren===

<pre>
$ cp /usr/local/src/phpstub/phpstub73 ~/doms/example.com/fastcgi/
$ cp /usr/local/src/phpstub/phpstub73 ~/doms/example.com/fastcgi-ssl/
</pre>

===phpstub für PHP 7.3 aktivieren===

In der jeweiligen <code>.htaccess</code> eines Ordners genügt, die PHP Dateizuordnung zu überschreiben:

<pre>
AddType application/x-httpd-php73 .php
Action application/x-httpd-php73 /fastcgi-bin/phpstub73
</pre>

Damit wird für den aktuellen Ordner und alle Unterordner PHP 7.3 verwendet.

== Eigene PHP Version ==
Es kann auch eine eigene PHP Version im Paket installiert werden.
Eine kurz Anleitung ist unter [[Eigene_PHP_Version]] beschrieben.

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Glossar]]
[[Kategorie:WWW]]

RubyOnRails

2013-07-08T14:42:56Z

Edv38: Änderung 3607 von Edv38 (Diskussion) rückgängig gemacht.

== Bestes Ruby on Rails Hosting bei Hostsharing ==

Rubyanwendungen laufen (wie alle Anwendungen bei Hostsharing) als Prozesse des jeweiligen Benutzersaccounts. Probleme mit Dateirechten und Sicherheitsrisiken, wie sie sonst bei der Ausführung durch den Webserver auftreten, sind so von vorne herein ausgeschlossen.

Standardmäßig erfolgt der Aufruf von Ruby Anwendungen durch den Apache Webserver über die FastCGI Schnittstelle. Dabei wird die Ruby Application Server Instanz des Users nach einem Aufruf noch für einige Zeit bereit gehalten, um sofort zur Bearbeitung von weiteren noch nicht gecacheten, oder gar nicht cachebaren, Anfragen zur Verfügung zu stehen.

Für den Betrieb von noch anspruchsvolleren Anwendungen haben wir auch Tools wie haproxy, varnish, nginx etc. installiert. Auf Anfrage können wir auch mod_passenger oder mongrel installieren. Anwender, die damit auf unserer leistungsfähigen Infrastruktur (managed Plattform) z.B. einen Webserver Cluster mit load-balancing realisieren möchten, brauchen bei uns dafür nur eigene Daemons zu buchen, können dies aber auch (für größere Projekte) mit einer beliebigen Anzahl ganzer Server realisieren.

== Einrichtung ohne zusätzliche Daemons (ein Application Server) ==

=== Vorbereitungen ===

Einige Einstellungen für den Paketuser.

~/.gemrc
install: --no-rdoc --no-ri
update: --no-rdoc --no-ri

~/.bashrc
alias gem="nice -n19 gem"

~/.profile
source "$HOME/.bashrc"

=== Ruby ===

==== Vorinstalliert ====

Soll nur die zentral installierte Ruby Version 1.8 verwendet werden, ergänzt man man in ~/.profile:
# enable user's own ruby installations, keeping all stuff below $HOME/.gem
export PATH="$HOME/bin:$HOME/.gem/ruby/1.8/bin:$PATH"
export GEM_PATH="$HOME/.gem/ruby/1.8:$( gem env gempath )"
export GEM_HOME="$HOME/.gem/ruby/1.8"

# Disabled for now, because using system libs caused undefined method error.
#export RUBYLIB="$HOME/.gem/ruby/1.8/lib:/usr/local/lib/site_ruby/1.8:/usr/lib/ruby/1.8"

# avoid to forget that extra parameter: ruby -rubygems prog_that_uses_gems
export RUBYOPT=rubygems

export RAILS_ENV=production

==== Eigene Installation ====

Um eine andere als die vorinstallierte Ruby Version zu verwenden, installiert man zunächst den Ruby Versions Manager (rvm),
curl -L https://get.rvm.io | bash -s stable
source ~/.rvm/scripts/rvm
rvm notes
rvm requirements
rvm pkg install openssl

und lässt dann die gewünschte Ruby Version installieren.
rvm install x.y.z

RVM passt die Umgebungsvariablen automatisch an die ausgewählt Version an. Die Version wählt man global per
rvm use x.y.z --default
oder nur für ein spezielles Verzeichnis:
cd ~/verzeichnis/mit/ruby-x.y.z-Anwendung
rvm use x.y.z-p??? --rvmrc

Zur Verwaltung von gems installiert man noch rubygems.
rvm rubygems current

=== Rails ===

Falls man die Ruby-Umgebung gerade erst eingerichtet hat, ohne sich zwischenzeitlich abzumelden, muß man zunächst die Umgebung manuell laden.
source ~/.profile

Nun kann Rails per "gem install rails" installiert werden (inklusive Abhängigkeiten).
Um spezielle versionen zu installieren kann man den gem Befehl mit "-v=x.y.z" ergänzen.

Zum Testen hier ein Beispiel das eine Content und Daten Management Anwendung installiert (http://zenadmin.org) und mit einer sqlite Datenbankdatei eingerichtet:
gem install rails -v=2.3.11
gem install i18n sexp_processor rmagick sqlite3 zena
zena new ~/doms/www.example.org/rails # Zena Rails-Anwendung anlegen.
cd ~/doms/www.example.org/rails
rake db:create # Datenbank anlegen.
zena migrate # Datenbank Tabellen einrichten.
zena mksite HOST_LANG=de RAILS_ENV=production PASSWORD=geheim HOST=www.example.org # Webseite anlegen.

=== Rails-Anwendung ===

Seine eigene Rails-Anwendung kopiert man z.B. nach ~/doms/www.example.org/rails, oder erstellt dort eine Neue (rails ~/doms/www.example.org/rails, ...).

=== Datenbank ===

Mit ''hsadmin'' beispielsweise einen Postgres-User (z.B. 'xyz00_rails', Passwort sei 'geheim') sowie eine Datenbank anlegen (z.B. 'xyz00_rails'.

Die Datenbank in der Anwendung konfigurieren,

cd ~/doms/www.example.org/rails/config/
nano database.yml

mit folgendem Inhalt:

production:
adapter: postgresql
database: xyz00_rails
host: localhost
username: xyz00_rails
password: geheim

=== E-Mail, Dateiablage ===

Beispielhafte Konfiguration:

default:
email_delivery:
delivery_method: :smtp
smtp_settings:
address: localhost
port: 25
domain: www.example.org
attachments_storage_path: /home/doms/www.example.org/rails/attach

=== Datenbankschema ===

Initialisieren und migrieren der Datenbank (je nach Rails-Anwendung).

cd ~/doms/www.example.org/rails
...
rake ...

=== Konfiguration von FastCGI ===

~/doms/www.example.org/htdocs/.htaccess

RewriteEngine On
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_FILENAME} dispatch.fcgi$
RewriteRule ^(.*)$ /fastcgi-bin/dispatch.fcgi [QSA,L]

Ältere Versionen von Rails, die noch nicht auf der "rack" Middleware aufbauen (wie obiges zena Beispiel), laufen mit folgender ~/doms/www.example.org/fastcgi/dispatch.fcgi

#!/usr/bin/env ruby
require "/home/doms/www.example.org/rails/config/environment"
require 'fcgi_handler'
RailsFCGIHandler.process!

Für aktuelle Versionen von Rails, die auf "rack" aufbauen, siehe https://github.com/dre3k/rails3_fcgi, ~/doms/www.example.org/fastcgi/dispatch.fcgi
#!/usr/bin/env ruby

require_relative '../config/environment'

class Rack::PathInfoRewriter
def initialize(app)
@app = app
end

def call(env)
env.delete('SCRIPT_NAME')
parts = env['REQUEST_URI'].split('?')
env['PATH_INFO'] = parts[0]
env['QUERY_STRING'] = parts[1].to_s
@app.call(env)
end
end

Rack::Handler::FastCGI.run Rack::PathInfoRewriter.new(HIER_APPLIKATIONSNAME_AUS_config/application.rb_EINTRAGEN::Application)

FastCGI-Skript ausführbar machen:

chmod 755 ~/doms/www.example.org/fastcgi/dispatch.fcgi

Am Anfang von ~/doms/www.example.org/rails/config/environment.rb einfügen:

ENV['RAILS_ENV'] ||= 'production'
ENV['GEM_PATH'] ||= '/home/pacs/xyz00/users/meinuser/.gem/ruby/1.8:/var/lib/gems/1.8'

Die Applikation ins Webroot einbinden:

cd ~/doms/www.example.org
# ggf. vorhandene Dateien sichern (oder nach ~/doms/www.example.org/rails/public kopieren),
mv htdocs htdocs.old
# und das entsprechende public/ Verzeichnis der Rails-Anwendung im Webroot verlinken.
# Standardmäsig /home/doms/www.example.org/rails/public,
# bei multi-site Anwendungen wie zena aber z.B. /home/doms/www.example.org/rails/site/www.example.org/public
ln -s /home/doms/www.example.org/rails/public htdocs

=== Konfiguration von SSL ===

Die Verzeichnisse ~/doms/www.example.org/fastcgi-ssl/ und ~/doms/www.example.org/htdocs-ssl/ werden analog zu bzw. anstelle von fastcgi und htdocs gefüllt.

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Glossar]]

RubyOnRails

2013-07-08T12:08:45Z

Edv38: fastcgi-Pfad in .htaccess Beispiel aktualisiert

== Bestes Ruby on Rails Hosting bei Hostsharing ==

Rubyanwendungen laufen (wie alle Anwendungen bei Hostsharing) als Prozesse des jeweiligen Benutzersaccounts. Probleme mit Dateirechten und Sicherheitsrisiken, wie sie sonst bei der Ausführung durch den Webserver auftreten, sind so von vorne herein ausgeschlossen.

Standardmäßig erfolgt der Aufruf von Ruby Anwendungen durch den Apache Webserver über die FastCGI Schnittstelle. Dabei wird die Ruby Application Server Instanz des Users nach einem Aufruf noch für einige Zeit bereit gehalten, um sofort zur Bearbeitung von weiteren noch nicht gecacheten, oder gar nicht cachebaren, Anfragen zur Verfügung zu stehen.

Für den Betrieb von noch anspruchsvolleren Anwendungen haben wir auch Tools wie haproxy, varnish, nginx etc. installiert. Auf Anfrage können wir auch mod_passenger oder mongrel installieren. Anwender, die damit auf unserer leistungsfähigen Infrastruktur (managed Plattform) z.B. einen Webserver Cluster mit load-balancing realisieren möchten, brauchen bei uns dafür nur eigene Daemons zu buchen, können dies aber auch (für größere Projekte) mit einer beliebigen Anzahl ganzer Server realisieren.

== Einrichtung ohne zusätzliche Daemons (ein Application Server) ==

=== Vorbereitungen ===

Einige Einstellungen für den Paketuser.

~/.gemrc
install: --no-rdoc --no-ri
update: --no-rdoc --no-ri

~/.bashrc
alias gem="nice -n19 gem"

~/.profile
source "$HOME/.bashrc"

=== Ruby ===

==== Vorinstalliert ====

Soll nur die zentral installierte Ruby Version 1.8 verwendet werden, ergänzt man man in ~/.profile:
# enable user's own ruby installations, keeping all stuff below $HOME/.gem
export PATH="$HOME/bin:$HOME/.gem/ruby/1.8/bin:$PATH"
export GEM_PATH="$HOME/.gem/ruby/1.8:$( gem env gempath )"
export GEM_HOME="$HOME/.gem/ruby/1.8"

# Disabled for now, because using system libs caused undefined method error.
#export RUBYLIB="$HOME/.gem/ruby/1.8/lib:/usr/local/lib/site_ruby/1.8:/usr/lib/ruby/1.8"

# avoid to forget that extra parameter: ruby -rubygems prog_that_uses_gems
export RUBYOPT=rubygems

export RAILS_ENV=production

==== Eigene Installation ====

Um eine andere als die vorinstallierte Ruby Version zu verwenden, installiert man zunächst den Ruby Versions Manager (rvm),
curl -L https://get.rvm.io | bash -s stable
source ~/.rvm/scripts/rvm
rvm notes
rvm requirements
rvm pkg install openssl

und lässt dann die gewünschte Ruby Version installieren.
rvm install x.y.z

RVM passt die Umgebungsvariablen automatisch an die ausgewählt Version an. Die Version wählt man global per
rvm use x.y.z --default
oder nur für ein spezielles Verzeichnis:
cd ~/verzeichnis/mit/ruby-x.y.z-Anwendung
rvm use x.y.z-p??? --rvmrc

Zur Verwaltung von gems installiert man noch rubygems.
rvm rubygems current

=== Rails ===

Falls man die Ruby-Umgebung gerade erst eingerichtet hat, ohne sich zwischenzeitlich abzumelden, muß man zunächst die Umgebung manuell laden.
source ~/.profile

Nun kann Rails per "gem install rails" installiert werden (inklusive Abhängigkeiten).
Um spezielle versionen zu installieren kann man den gem Befehl mit "-v=x.y.z" ergänzen.

Zum Testen hier ein Beispiel das eine Content und Daten Management Anwendung installiert (http://zenadmin.org) und mit einer sqlite Datenbankdatei eingerichtet:
gem install rails -v=2.3.11
gem install i18n sexp_processor rmagick sqlite3 zena
zena new ~/doms/www.example.org/rails # Zena Rails-Anwendung anlegen.
cd ~/doms/www.example.org/rails
rake db:create # Datenbank anlegen.
zena migrate # Datenbank Tabellen einrichten.
zena mksite HOST_LANG=de RAILS_ENV=production PASSWORD=geheim HOST=www.example.org # Webseite anlegen.

=== Rails-Anwendung ===

Seine eigene Rails-Anwendung kopiert man z.B. nach ~/doms/www.example.org/rails, oder erstellt dort eine Neue (rails ~/doms/www.example.org/rails, ...).

=== Datenbank ===

Mit ''hsadmin'' beispielsweise einen Postgres-User (z.B. 'xyz00_rails', Passwort sei 'geheim') sowie eine Datenbank anlegen (z.B. 'xyz00_rails'.

Die Datenbank in der Anwendung konfigurieren,

cd ~/doms/www.example.org/rails/config/
nano database.yml

mit folgendem Inhalt:

production:
adapter: postgresql
database: xyz00_rails
host: localhost
username: xyz00_rails
password: geheim

=== E-Mail, Dateiablage ===

Beispielhafte Konfiguration:

default:
email_delivery:
delivery_method: :smtp
smtp_settings:
address: localhost
port: 25
domain: www.example.org
attachments_storage_path: /home/doms/www.example.org/rails/attach

=== Datenbankschema ===

Initialisieren und migrieren der Datenbank (je nach Rails-Anwendung).

cd ~/doms/www.example.org/rails
...
rake ...

=== Konfiguration von FastCGI ===

~/doms/www.example.org/htdocs/.htaccess

RewriteEngine On
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_FILENAME} dispatch.fcgi$
RewriteRule ^(.*)$ /fastcgi/dispatch.fcgi [QSA,L]

Ältere Versionen von Rails, die noch nicht auf der "rack" Middleware aufbauen (wie obiges zena Beispiel), laufen mit folgender ~/doms/www.example.org/fastcgi/dispatch.fcgi

#!/usr/bin/env ruby
require "/home/doms/www.example.org/rails/config/environment"
require 'fcgi_handler'
RailsFCGIHandler.process!

Für aktuelle Versionen von Rails, die auf "rack" aufbauen, siehe https://github.com/dre3k/rails3_fcgi, ~/doms/www.example.org/fastcgi/dispatch.fcgi
#!/usr/bin/env ruby

require_relative '../config/environment'

class Rack::PathInfoRewriter
def initialize(app)
@app = app
end

def call(env)
env.delete('SCRIPT_NAME')
parts = env['REQUEST_URI'].split('?')
env['PATH_INFO'] = parts[0]
env['QUERY_STRING'] = parts[1].to_s
@app.call(env)
end
end

Rack::Handler::FastCGI.run Rack::PathInfoRewriter.new(HIER_APPLIKATIONSNAME_AUS_config/application.rb_EINTRAGEN::Application)

FastCGI-Skript ausführbar machen:

chmod 755 ~/doms/www.example.org/fastcgi/dispatch.fcgi

Am Anfang von ~/doms/www.example.org/rails/config/environment.rb einfügen:

ENV['RAILS_ENV'] ||= 'production'
ENV['GEM_PATH'] ||= '/home/pacs/xyz00/users/meinuser/.gem/ruby/1.8:/var/lib/gems/1.8'

Die Applikation ins Webroot einbinden:

cd ~/doms/www.example.org
# ggf. vorhandene Dateien sichern (oder nach ~/doms/www.example.org/rails/public kopieren),
mv htdocs htdocs.old
# und das entsprechende public/ Verzeichnis der Rails-Anwendung im Webroot verlinken.
# Standardmäsig /home/doms/www.example.org/rails/public,
# bei multi-site Anwendungen wie zena aber z.B. /home/doms/www.example.org/rails/site/www.example.org/public
ln -s /home/doms/www.example.org/rails/public htdocs

=== Konfiguration von SSL ===

Die Verzeichnisse ~/doms/www.example.org/fastcgi-ssl/ und ~/doms/www.example.org/htdocs-ssl/ werden analog zu bzw. anstelle von fastcgi und htdocs gefüllt.

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Glossar]]