Hostsharing Wiki - Benutzerbeiträge [de]

OpenProject installieren

2025-07-18T13:21:22Z

Opa00-hostsharing: /* Upgrade durchführen */

== Allgemein ==
OpenProject ist eine umfangreiche Projektmanagement-Software. Die Software ist multiprojektfähig; für jedes Projekt stehen unter anderem folgende Werkzeuge zur Verfügung:
* Wiki
* Vorgangsverfolgung (Ticketsystem, Issue Tracker)
* Zeiterfassung
* Dokument- und Dateiverwaltung

Diese Anleitung beschreibt, wie man OpenProject auf der Managed Hosting Plattform von Hostsharing installieren kann. OpenProject lässt sich in jedem Managed Webspace betreiben.

Die Anleitung wurde für OpenProject Version 11 erstellt.

== Ansible Skript ==

Alternativ zur manuellen Installation, die in diesem Wiki Artikel beschrieben wird, gibt es ein
Ansible Skript, das die Installationsschritte für OpenProject automatisiert durchführt.

Die Quellen für das Ansible Skript können hier eingesehen werden: https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/openproject

== Vorbereitungen ==

=== Service-User, Domain und Datenbank ===

Mit Hilfe von HSAdmin werden angelegt:
# Ein User als Service-User mit ''/bin/bash'' als Shell, zum Beispiel Beispiel: ''xyz00-project"
# Eine Domain mit ''xyz00-project'' als Domain-Administrator, zum Beispiel "prj.example.com"
# Einen Postgresql-User ''xyz00_dbuser'' mit Passwort ''meinPasswort''
# Eine Postgresql-Datenbank ''xyz00_prjdb'' mit Datenbank-Owner ''xyz00_dbuser''

=== Vorbereitung des Webspace ===

Die "leichtgewichtige" Subdomain "www" wird gelöscht. Ebenso die ''.htaccess''-Datei mit der Weiterleitung dorthin.

<syntaxhighlight lang="bash">
xyz00@h20 $ sudo -u xyz00-project -i
xyz00-project@h20:~$ cd ~/doms/projekt.example.com/
xyz00-project@h20:~/doms/projekt.example.com$ rm -rf subs/www/ subs-ssl/www/ htdocs-ssl/.htaccess
</syntaxhighlight>

=== Installation von Ruby ===

Weiterhin benötigt OpenProject eine geeignete Version der Programmiersprache Ruby.

Die gewünschte Version kann hier abgelesen werden: https://github.com/opf/openproject/blob/stable/11/.ruby-version

Die Installation-Anleitung für OpenProject schlägt für die Installation ''rbenv'' vor.

<syntaxhighlight lang="bash">
xyz00-project@h20:~/doms/projekt.example.com$ cd
xyz00-project@h20:~$ git clone https://github.com/sstephenson/rbenv.git ~/.rbenv
xyz00-project@h20:~$ touch .profile
xyz00-project@h20:~$ chmod u+x .profile
xyz00-project@h20:~$ echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.profile
xyz00-project@h20:~$ echo 'eval "$(rbenv init -)"' >> ~/.profile
xyz00-project@h20:~$ source ~/.profile
xyz00-project@h20:~$ git clone https://github.com/sstephenson/ruby-build.git ~/.rbenv/plugins/ruby-build
xyz00-project@h20:~$ rbenv install 2.7.4
xyz00-project@h20:~$ rbenv rehash
xyz00-project@h20:~$ rbenv global 2.7.4
</syntaxhighlight>

Als Test bitte aufrufen: ''ruby -v''

Die Anzeige sollte etwa das Folgende enthalten:
ruby 2.7.4pXYZ (....) [x86_64-linux]

=== Installation von Node ===

Die Installation-Anleitung für OpenProject schlägt für die Installation ''nodenv'' vor.

<syntaxhighlight lang="bash">
xyz00-project@h20:~$ git clone https://github.com/OiNutter/nodenv.git ~/.nodenv
xyz00-project@h20:~$ echo 'export PATH="$HOME/.nodenv/bin:$PATH"' >> ~/.profile
xyz00-project@h20:~$ echo 'eval "$(nodenv init -)"' >> ~/.profile
xyz00-project@h20:~$ source ~/.profile
xyz00-project@h20:~$ git clone git://github.com/OiNutter/node-build.git ~/.nodenv/plugins/node-build
xyz00-project@h20:~$ nodenv install 12.18.4
xyz00-project@h20:~$ nodenv rehash
xyz00-project@h20:~$ nodenv global 12.18.4
</syntaxhighlight>

Ein Test mit ''node --version'' solte anzeigen: v12.18.4

== Installation und Konfiguration ==

=== Installation von OpenProject ===

Wir installieren die OpenProject Community Edition. siehe https://github.com/opf/openproject

<syntaxhighlight lang="bash">
xyz00-project@h20:~$ git clone https://github.com/opf/openproject.git --branch stable/11 --depth 1
xyz00-project@h20:~$ cd ~/openproject
xyz00-project@h20:~$ gem update --system
xyz00-project@h20:~$ gem install bundler
xyz00-project@h20:~$ bundle update --bundler
xyz00-project@h20:~$ bundle config set deployment 'true'
xyz00-project@h20:~$ bundle config set without 'mysql2 sqlite development test therubyracer docker'
xyz00-project@h20:~$ bundle install
xyz00-project@h20:~$ npm install
</syntaxhighlight>

=== Konfiguration von OpenProject ===

Erstelle eine Konfiguration für den Datenbank-Zugriff in der Datei ''config/database.yml''

<syntaxhighlight lang="bash">
xyz00-project@h20:~$ cd ~/openproject
xyz00-project@h20:~/openproject$ cp config/database.yml.example config/database.yml
</syntaxhighlight>

In der neuen Datei ''database.yml'' wird die mit HSAdmin angelegte PostgreSQL-Datenbank eingetragen:
<syntaxhighlight lang="yaml" line>
production:
adapter: postgresql
encoding: unicode
host: localhost
database: xyz00_prjdb (wie oben angegeben)
pool: 10
username: xyz00_dbuser (wie oben angegeben)
password: meinPasswort (wie oben angegeben)
</syntaxhighlight>

Die Einträge für ''development'' und ''test'' können gelöscht werden.

Dann wird die Datei ''configuration.yml'' angelegt:

<syntaxhighlight lang="yaml" line>
xyz00-project@h20:~$ cd ~/openproject
xyz00-project@h20:~/openproject$ cp config/configuration.yml.example config/configuration.yml
</syntaxhighlight>

Dort erfolgen die Einstellungen für ausgehende E-Mails:

<syntaxhighlight lang="yaml" line>
default:
log_level: info
email_delivery_method: :smtp
smtp_address: localhost
smtp_port: 25
smtp_domain: example.com
#smtp_authentication: :login
#smtp_user_name: "openproject@example.net"
#smtp_password: "my_openproject_password"
</syntaxhighlight>

Die Zeilen mit smtp_authentication, smtp_user_name und smtp_password können auskommentiert werden, sie werden in unserem Setup nicht benötigt.

Es muss außerdem vermieden werden, dass beim Hochladen von Dateien in /tmp geschrieben wird. Dazu wird das Verzeichnis $HOME/var/tmp angelegt, und die Datei <code>openproject/config/initializers/tmpdir.rb</code> mit folgendem Inhalt erstellt:

<syntaxhighlight lang="ruby" line>
class Dir
def self.tmpdir
"/home/pacs/xyz00/users/project/var/tmp/"
end
end
</syntaxhighlight>

=== Einen geheimen Schlüssel erzeugen ===

<syntaxhighlight lang=bash>
xyz00-project@h20:~$ cd ~/openproject
xyz00-project@h20:~/openproject$ EDITOR=cat ./bin/rails credentials:edit
</syntaxhighlight>

=== Initialisiere Datenbank und erzeuge Web-Ressourcen ===

<syntaxhighlight lang=bash>
xyz00-project@h20:~$ cd ~/openproject
xyz00-project@h20:~/openproject$ export RAILS_ENV="production"
xyz00-project@h20:~/openproject$ source ~/.profile
xyz00-project@h20:~/openproject$ ./bin/rails db:prepare
xyz00-project@h20:~/openproject$ ./bin/rake assets:precompile
</syntaxhighlight>

=== Anlegen des Administrators ===

Es kann eine Demo Installation installiert werden:
<syntaxhighlight lang=bash>
xyz00-project@h20:~$ cd ~/openproject
xyz00-project@h20:~/openproject$ export RAILS_ENV="production"
xyz00-project@h20:~/openproject$ source ~/.profile
xyz00-project@h20:~/openproject$ LOCALE=en ./bin/rake db:seed
</syntaxhighlight>

Damit wird ein Beispiel-Projekt angelegt, das man wieder löschen kann.

Wichtig ist aber, dass der Benutzer <code>admin</code> mit dem Passwort <code>admin</code> angelegt wird. Das Passwort muss bei der ersten Anmeldung geändert werden.

=== Konfiguration in Passenger ===

<syntaxhighlight lang=bash>
xyz00-project@h20:~$ cd ~/doms/prj.example.com
xyz00-project@h20:~/doms/prj.example.com$ rm -rf app-ssl htdocs-ssl
xyz00-project@h20:~/doms/prj.example.com$ ln -s $HOME/openproject app-ssl
xyz00-project@h20:~/doms/prj.example.com$ ln -s $HOME/openproject/public htdocs-ssl
</syntaxhighlight>

Weiterhin muss in einer .htaccess-Datei in diesem Verzeichnis die richtige Umgebung gesetzt sein:

<syntaxhighlight lang=apache>
# xyz00-project@h20:~/doms/prj.example.com$ cat .htaccess

SetEnv OPENPROJECT_STORAGE_TMP__PATH /home/pacs/xyz00/users/project/var/tmp/
SetEnv TMPDIR /home/pacs/xyz00/users/project/var/tmp/
PassengerRuby /home/pacs/xyz00/users/project/.rbenv/shims/ruby
</syntaxhighlight>

== Aufsetzen des systemd Timers für Hintergrundprozesse ==

Es werden Benachrichtigungs-E-Mails im Hintergrund verschickt. Dazu muss ein Prozess im Hintergrund gestartet werden. Um Probleme zu vermeiden, dass source nicht zur Verfügung steht, kann der Aufruf in einer eigenen Skriptdatei geschehen, die zwingend mit Bash ausgeführt wird, wo source verfügbar ist.

Datei ''/home/pacs/xyz00/users/project/emailjob.sh'':

<syntaxhighlight lang=bash line>
#!/bin/bash
source ~/.profile
cd ~/openproject
RAILS_ENV="production" ./bin/rake jobs:workoff
</syntaxhighlight>

Datei ''/home/pacs/xyz00/users/project/jobrestart.sh'':

<syntaxhighlight lang=bash line>
#!/bin/bash
source ~/.profile
cd ~/openproject
RAILS_ENV="production" ./bin/delayed_job restart
</syntaxhighlight>

Nun können die Timer eingerichtet werden:

''~/.config/systemd/user/openproject_emails.service''
<syntaxhighlight lang=ini line>
[Unit]
Description=openproject mails

[Service]
Type=oneshot
ExecStart=/home/pacs/xyz00/users/project/emailjob.sh
</syntaxhighlight>

~/.config/systemd/user/openproject_emails.timer
<syntaxhighlight lang=ini line>
[Unit]
Description=openproject mails

[Timer]
OnCalendar=*:0/2
Persistent=True

[Install]
WantedBy=timers.target
</syntaxhighlight>

Damit wird der Hintergrundprozess alle 2 Minuten gestartet.

Es gibt noch einen Hintergrundjob, den ich einmal in der Stunde neu starte:

''~/.config/systemd/user/openproject_jobrestart.service''
<syntaxhighlight lang=ini line>
[Unit]
Description=openproject restart job

[Service]
Type=oneshot
ExecStart=/home/pacs/xyz00/users/project/jobrestart.sh
</syntaxhighlight>

~/.config/systemd/user/openproject_jobrestart.timer
<syntaxhighlight lang=ini line>
[Unit]
Description=openproject restart job

[Timer]
OnCalendar=*:22
Persistent=True

[Install]
WantedBy=timers.target
</syntaxhighlight>

Timer aktivieren und starten:
<syntaxhighlight lang=bash line>
$ systemctl --user enable openproject_emails.timer
$ systemctl --user start openproject_emails.timer
$ systemctl --user enable openproject_jobrestart.timer
$ systemctl --user start openproject_jobrestart.timer
</syntaxhighlight>

== Upgrade durchführen ==

Die gewünschte Ruby Version kann hier abgelesen werden (ggf. Branch passend wechseln): https://github.com/opf/openproject/blob/stable/11/.ruby-version

Die benötigte Nodejs Version kann im git repository in der package.json unter engine abgelesen werden.

Für das Upgrade von OpenProject 11.2.4 auf 11.3.4, musste eine neue Version von Ruby installiert werden:

<syntaxhighlight lang=bash>
xyz00-project@h20:~$ cd ~/openproject
xyz00-project@h20:~/openproject$ source ~/.profile
xyz00-project@h20:~/openproject$ git -C $HOME/.rbenv/plugins/ruby-build pull
xyz00-project@h20:~/openproject$ rbenv install 2.7.4
xyz00-project@h20:~/openproject$ rbenv rehash
xyz00-project@h20:~/openproject$ rbenv global 2.7.4
xyz00-project@h20:~/openproject$ source ~/.profile
xyz00-project@h20:~/openproject$ rm -Rf $HOME/.rbenv/versions/2.7.3/ # alte Version kann gelöscht werden
</syntaxhighlight>

Weil das Git Repository bei der Erstinstallation nur einen Branch enthielt, muss nun das Repository passend nachgeladen werden (Beispielhaft für den Branch stable/15)

<syntaxhighlight lang=bash>
xyz00-project@h20:~$ cd openproject
xyz00-project@h20:~/openproject$ source ~/.profile
xyz00-project@h20:~/openproject$ git remote set-branches --add origin stable/15
xyz00-project@h20:~/openproject$ git fetch
xyz00-project@h20:~/openproject$ git checkout stable/15
</syntaxhighlight>

Nach Verifikation dass das update erfolgreich war, kann der alte Branch gelöscht werden, nach bedarf mit:

<syntaxhighlight lang=bash>
xyz00-project@h20:~$ git branch -D old_branch_name
</syntaxhighlight>

Generell müssen diese Schritte durchgeführt werden:

<syntaxhighlight lang=bash>
xyz00-project@h20:~$ cd openproject
xyz00-project@h20:~/openproject$ source ~/.profile
xyz00-project@h20:~/openproject$ git fetch
xyz00-project@h20:~/openproject$ git pull
xyz00-project@h20:~/openproject$ gem update --system
xyz00-project@h20:~/openproject$ bundle install
xyz00-project@h20:~/openproject$ npm install
xyz00-project@h20:~/openproject$ export RAILS_ENV="production"
xyz00-project@h20:~/openproject$ ./bin/rake db:migrate
xyz00-project@h20:~/openproject$ ./bin/rake assets:precompile
xyz00-project@h20:~/openproject$ touch ~/doms/prj.example.com/app-ssl/tmp/restart.txt
</syntaxhighlight>

Falls es ein Update der Ruby Version gab muss die neue Version ggf. noch im HS Admin für Passenger eingetragen werden.

== Referenzen ==

* [https://docs.openproject.org/installation-and-operations/installation/manual/ Anleitung für die manuelle Installation]
* [https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/openproject Ansible Playbook für Hostsharing]
----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:Software]]
[[Kategorie:RubyOnRails]]
[[Kategorie:Passenger]]
[[Kategorie:Projektmanagement]]
[[Kategorie:Projektverwaltung]]

Etherpad Installieren

2025-03-06T00:14:49Z

Opa00-hostsharing: /* Etherpad Lite installieren */

= Etherpad Lite installieren =

Etherpad ist eine JavaScript-Anwendung mit der mehrere Bearbeiter gleichzeitig einen Text im Browser editieren können.

Mit Hilfe von Etherpad können zum Beispiel die Teilnehmer einer Telefonkonferenz gemeinsam an einem Text-Dokument arbeiten.

== Vorbereitung ==

Als Paket-Admin ''xyz00'' werden mit HSAdmin ein User angelegt und eine Domain aufgeschaltet. Eine produktive Installation von Etherpad braucht zusätzlich einen MySQL-User und eine MySQL-Datenbank.

Mit ''hsscript'' können diese Ressourcen wie folgt angelegt werden:

Als Paketadmin ''xyz00'' aufrufen: <code>hsscript -i</code>

In der HSAdmin-Shell gibt man dann ein:

<syntaxhighlight lang=shell>
xyz00@hsadmin> user.add({set:{name:'xyz00-pad', password:'mein-Geheimwort', shell:'/bin/bash'}})
xyz00@hsadmin> domain.add({set:{name:'pad.example.com', user:'xyz00-pad'}})
xyz00@hsadmin> mysqluser.add({set:{name:'xyz00_padusr', password:'anderes-Geheimwort'}})
xyz00@hsadmin> mysqldb.add({set:{name:'xyz00_paddb', owner:'xyz00_padusr'}})
xyz00@hsadmin> bye
</syntaxhighlight>

== Installation ==

Etherpad v2.2.7 benötigt ''nodejs'' in einer Version > 18.18. Die Installation erfolgt gemäß der Wiki-Anleitung: [[NodeJS]]

Zusätzlich muss der Paketmanager pnpm für Version 2 vorgehalten werden

npm install pnpm@latest-10

Als Paketadmin ''xyz00'' nimmt man mit <code>sudo -u xyz00-pad -i</code> die Rechte des Domain-Administrators ''xyz00-pad'' für die neue Domain ''pad.example.com'' an.

Die Etherpad-Software kann aus dem Git-Repository bei Github ausgecheckt werden:

<syntaxhighlight lang=shell>
cd
git clone https://github.com/ether/etherpad-lite.git
cd etherpad-lite/
git tag -l
git checkout tags/2.2.7
./bin/run.sh
</syntaxhighlight>

Mit "git checkout tags/2.2.7" wird Release 2.2.7 ausgecheckt, die heute (06.03.2025) aktuelle Version.

Bei der Initialisierung der Anwendung gibt es einige Warnungen, die man ignorieren kann. Wenn die Initialisierung durchgelaufen ist, kann man
unter der URL http://xyz00.hostsharing.net:9001/ schon die die Etherpad-Anwendung ohne Datenbank und ohne die gewünschte Domain sehen.

Wir brechen das ''run.sh''-Skript mit Ctrl-c ab.

== v2: Konfiguration mit Proxy und systemd ==

#.config/systemd/user/etherpad-lite.service
[Unit]
Description=Etherpad-Lite Service
[Service]
WorkingDirectory=%h/etherpad-lite
Environment="NODE_ENV=production"
Environment="BIND=127.0.0.1"
Environment="PATH=/home/pacs/xyz00/users/tools_pad/.nvm/versions/node/v20.18.3/bin:/usr/local/bin:/usr/bin:/bin"
ExecStart=%h/.nvm/versions/node/v20.18.3/bin/pnpm run prod
[Install]
WantedBy=default.target

#~/doms/pad.example.com/.htaccess
DirectoryIndex disabled
RewriteBase /
RewriteCond %{HTTP:Connection} Upgrade [NC]
RewriteCond %{HTTP:Upgrade} websocket [NC]
RewriteRule .* ws://localhost:9001%{REQUEST_URI} [proxy]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule .* http://localhost:9001%{REQUEST_URI} [proxy]

Wichtig ist, dass auf 127.0.0.1 ge-binded wird, und nicht die von Welt erreichbare Adresse 0.0.0.0. Man beachte das im Systemd Service File die node version hardcoded wird und beim Update zwei mal entsprechend angepasst werden muss. Genauso der User und der Paketusername, der leider nicht direkt ersetzt werden kann.

Dass auch nach Neustart der Etherpad Server erreichbar ist:

systemctl --user enable etherpad-lite

== v1: Konfiguration für Apache und Passenger ==

Vor der Nutzung von [[Phusion Passenger]] bitte unbedingt die dortigen Hinweise zur Nutzung beachten.

Die statischen Dateien der Anwendung werden mit den folgenden Befehlen richtig verlinkt
(immer noch als User ''xyz00-pad''):

<syntaxhighlight lang=shell>
cd
cd ~/doms/pad.example.com
rm -rf subs/www
rm -rf subs-ssl/www
rm -rf htdocs-ssl
ln -s ~/etherpad-lite/src/static htdocs-ssl
</syntaxhighlight>

Für die Anwendung legen wir im Verzeichnis ''~/doms/pad.example.com/app-ssl/'' eine Datei app.js mit dem folgenden Inhalt an:

<syntaxhighlight lang=javascript>
require('/home/pacs/xyz00/users/pad/etherpad-lite/node_modules/ep_etherpad-lite/node/server.js');
process.chdir('/home/pacs/xyz00/users/pad/etherpad-lite');
</syntaxhighlight>

= Datenbank anpassen =

Zum Schluß wird in der Datei ''~/etherpad-lite/settings.js'' noch die MySQL-Datenbank konfiguriert. Dazu muss der Teil mit ''dbType: mysql'' aktiv (nicht auskommentiert) sein. Etwa wie folgt:

<syntaxhighlight lang=javascript>
"dbType" : "mysql",
"dbSettings" : {
"user" : "xyz00_padusr",
"host" : "localhost",
"password": "anderes-Geheimwort",
"database": "xyz00_paddb",
"charset" : "utf8mb4",
"insecureAuth": "true"
},
</syntaxhighlight>

Die Einstellungen für den ''dbType: dirty'' werden dafür entfernt.

Weiter unten in der Datei kann dann noch ein Admin-User aktiviert werden.

Etherpad sollte nun unter der URL: ''http://pad.example.com/'' erreichbar sein.

= Update =

Etherpad ist sehr pflegeleicht was das Update angeht. Es muss nur die neue Version in Git ausgecheckt werden und ./bin/run.sh erneut (einmalig) ausgeführt werden, damit die dependencies wieder neu gebaut werden. Auch von v1 -> v2 ist sonst nichts weiter zu tun.

= Links =

*[http://etherpad.org/ Etherpad Homepage (Englisch)]
*[https://github.com/ether/etherpad-lite/ Github Repository (Englisch)]
*[https://github.com/ether/etherpad-lite/wiki/Running-Etherpad-on-Phusion-Passenger Running Etherpad on Phusion Passenger (Englisch)]

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Passenger]]
[[Kategorie:NodeJS]]

Etherpad Installieren

2025-03-06T00:13:55Z

Opa00-hostsharing: /* v2: Konfiguration mit Proxy und systemd */

= Etherpad Lite installieren =

Etherpad ist eine JavaScript-Anwendung mit der mehrere Bearbeiter gleichzeitig einen Text im Browser editieren können.

Mit Hilfe von Etherpad können zum Beispiel die Teilnehmer einer Telefonkonferenz gemeinsam an einem Text-Dokument arbeiten.

== Vorbereitung ==

Als Paket-Admin ''xyz00'' werden mit HSAdmin ein User angelegt und eine Domain aufgeschaltet. Eine produktive Installation von Etherpad braucht zusätzlich einen MySQL-User und eine MySQL-Datenbank.

Mit ''hsscript'' können diese Ressourcen wie folgt angelegt werden:

Als Paketadmin ''xyz00'' aufrufen: <code>hsscript -i</code>

In der HSAdmin-Shell gibt man dann ein:

<syntaxhighlight lang=shell>
xyz00@hsadmin> user.add({set:{name:'xyz00-pad', password:'mein-Geheimwort', shell:'/bin/bash'}})
xyz00@hsadmin> domain.add({set:{name:'pad.example.com', user:'xyz00-pad'}})
xyz00@hsadmin> mysqluser.add({set:{name:'xyz00_padusr', password:'anderes-Geheimwort'}})
xyz00@hsadmin> mysqldb.add({set:{name:'xyz00_paddb', owner:'xyz00_padusr'}})
xyz00@hsadmin> bye
</syntaxhighlight>

== Installation ==

Etherpad v2.2.7 benötigt ''nodejs'' in einer Version > 18.18. Die Installation erfolgt gemäß der Wiki-Anleitung: [[NodeJS]]

Zusätzlich muss der Paketmanager pnpm für Version 2 vorgehalten werden

npm install pnpm@latest-10

Als Paketadmin ''xyz00'' nimmt man mit <code>sudo -u xyz00-pad -i</code> die Rechte des Domain-Administrators ''xyz00-pad'' für die neue Domain ''pad.example.com'' an.

Die Etherpad-Software kann aus dem Git-Repository bei Github ausgecheckt werden:

<syntaxhighlight lang=shell>
cd
git clone https://github.com/ether/etherpad-lite.git
cd etherpad-lite/
git tag -l
git checkout tags/2.2.7
./bin/run.sh
</syntaxhighlight>

Mit "git checkout tags/2.2.7" wird Release 2.2.7 ausgecheckt, die heute (06.03.2025) aktuelle Version.

Bei der Initialisierung der Anwendung gibt es einige Warnungen, die man ignorieren kann. Wenn die Initialisierung durchgelaufen ist, kann man
unter der URL http://xyz00.hostsharing.net:9001/ schon die die Etherpad-Anwendung ohne Datenbank und ohne die gewünschte Domain sehen.

Wir brechen das ''run.sh''-Skript mit Ctrl-c ab.

== v2: Konfiguration mit Proxy und systemd ==

#.config/systemd/user/etherpad-lite.service
[Unit]
Description=Etherpad-Lite Service
[Service]
WorkingDirectory=%h/etherpad-lite
Environment="NODE_ENV=production"
Environment="BIND=127.0.0.1"
Environment="PATH=/home/pacs/xyz00/users/tools_pad/.nvm/versions/node/v20.18.3/bin:/usr/local/bin:/usr/bin:/bin"
ExecStart=%h/.nvm/versions/node/v20.18.3/bin/pnpm run prod
[Install]
WantedBy=default.target

#~/doms/pad.example.com/.htaccess
DirectoryIndex disabled
RewriteBase /
RewriteCond %{HTTP:Connection} Upgrade [NC]
RewriteCond %{HTTP:Upgrade} websocket [NC]
RewriteRule .* ws://localhost:9001%{REQUEST_URI} [proxy]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule .* http://localhost:9001%{REQUEST_URI} [proxy]

Wichtig ist, dass auf 127.0.0.1 ge-binded wird, und nicht die von Welt erreichbare Adresse 0.0.0.0. Man beachte das im Systemd Service File die node version hardcoded wird und beim Update zwei mal entsprechend angepasst werden muss. Genauso der User und der Paketusername, der leider nicht direkt ersetzt werden kann.

Dass auch nach Neustart der Etherpad Server erreichbar ist:

systemctl --user enable etherpad-lite

== v1: Konfiguration für Apache und Passenger ==

Vor der Nutzung von [[Phusion Passenger]] bitte unbedingt die dortigen Hinweise zur Nutzung beachten.

Die statischen Dateien der Anwendung werden mit den folgenden Befehlen richtig verlinkt
(immer noch als User ''xyz00-pad''):

<syntaxhighlight lang=shell>
cd
cd ~/doms/pad.example.com
rm -rf subs/www
rm -rf subs-ssl/www
rm -rf htdocs-ssl
ln -s ~/etherpad-lite/src/static htdocs-ssl
</syntaxhighlight>

Für die Anwendung legen wir im Verzeichnis ''~/doms/pad.example.com/app-ssl/'' eine Datei app.js mit dem folgenden Inhalt an:

<syntaxhighlight lang=javascript>
require('/home/pacs/xyz00/users/pad/etherpad-lite/node_modules/ep_etherpad-lite/node/server.js');
process.chdir('/home/pacs/xyz00/users/pad/etherpad-lite');
</syntaxhighlight>

Zum Schluß wird in der Datei ''~/etherpad-lite/settings.js'' noch die MySQL-Datenbank konfiguriert. Dazu muss der Teil mit ''dbType: mysql'' aktiv (nicht auskommentiert) sein. Etwa wie folgt:

<syntaxhighlight lang=javascript>
"dbType" : "mysql",
"dbSettings" : {
"user" : "xyz00_padusr",
"host" : "localhost",
"password": "anderes-Geheimwort",
"database": "xyz00_paddb",
"charset" : "utf8mb4",
"insecureAuth": "true"
},
</syntaxhighlight>

Die Einstellungen für den ''dbType: dirty'' werden dafür entfernt.

Weiter unten in der Datei kann dann noch ein Admin-User aktiviert werden.

Etherpad sollte nun unter der URL: ''http://pad.example.com/'' erreichbar sein.

== Update ==

Etherpad ist sehr pflegeleicht was das Update angeht. Es muss nur die neue Version in Git ausgecheckt werden und ./bin/run.sh erneut (einmalig) ausgeführt werden, damit die dependencies wieder neu gebaut werden. Auch von v1 -> v2 ist sonst nichts weiter zu tun.

== Links ==

*[http://etherpad.org/ Etherpad Homepage (Englisch)]
*[https://github.com/ether/etherpad-lite/ Github Repository (Englisch)]
*[https://github.com/ether/etherpad-lite/wiki/Running-Etherpad-on-Phusion-Passenger Running Etherpad on Phusion Passenger (Englisch)]

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Passenger]]
[[Kategorie:NodeJS]]

Etherpad Installieren

2025-03-06T00:12:28Z

Opa00-hostsharing: update zu v2

= Etherpad Lite installieren =

Etherpad ist eine JavaScript-Anwendung mit der mehrere Bearbeiter gleichzeitig einen Text im Browser editieren können.

Mit Hilfe von Etherpad können zum Beispiel die Teilnehmer einer Telefonkonferenz gemeinsam an einem Text-Dokument arbeiten.

== Vorbereitung ==

Als Paket-Admin ''xyz00'' werden mit HSAdmin ein User angelegt und eine Domain aufgeschaltet. Eine produktive Installation von Etherpad braucht zusätzlich einen MySQL-User und eine MySQL-Datenbank.

Mit ''hsscript'' können diese Ressourcen wie folgt angelegt werden:

Als Paketadmin ''xyz00'' aufrufen: <code>hsscript -i</code>

In der HSAdmin-Shell gibt man dann ein:

<syntaxhighlight lang=shell>
xyz00@hsadmin> user.add({set:{name:'xyz00-pad', password:'mein-Geheimwort', shell:'/bin/bash'}})
xyz00@hsadmin> domain.add({set:{name:'pad.example.com', user:'xyz00-pad'}})
xyz00@hsadmin> mysqluser.add({set:{name:'xyz00_padusr', password:'anderes-Geheimwort'}})
xyz00@hsadmin> mysqldb.add({set:{name:'xyz00_paddb', owner:'xyz00_padusr'}})
xyz00@hsadmin> bye
</syntaxhighlight>

== Installation ==

Etherpad v2.2.7 benötigt ''nodejs'' in einer Version > 18.18. Die Installation erfolgt gemäß der Wiki-Anleitung: [[NodeJS]]

Zusätzlich muss der Paketmanager pnpm für Version 2 vorgehalten werden

npm install pnpm@latest-10

Als Paketadmin ''xyz00'' nimmt man mit <code>sudo -u xyz00-pad -i</code> die Rechte des Domain-Administrators ''xyz00-pad'' für die neue Domain ''pad.example.com'' an.

Die Etherpad-Software kann aus dem Git-Repository bei Github ausgecheckt werden:

<syntaxhighlight lang=shell>
cd
git clone https://github.com/ether/etherpad-lite.git
cd etherpad-lite/
git tag -l
git checkout tags/2.2.7
./bin/run.sh
</syntaxhighlight>

Mit "git checkout tags/2.2.7" wird Release 2.2.7 ausgecheckt, die heute (06.03.2025) aktuelle Version.

Bei der Initialisierung der Anwendung gibt es einige Warnungen, die man ignorieren kann. Wenn die Initialisierung durchgelaufen ist, kann man
unter der URL http://xyz00.hostsharing.net:9001/ schon die die Etherpad-Anwendung ohne Datenbank und ohne die gewünschte Domain sehen.

Wir brechen das ''run.sh''-Skript mit Ctrl-c ab.

== v2: Konfiguration mit Proxy und systemd ==

#.config/systemd/user/etherpad-lite.service
[Unit]
Description=Etherpad-Lite Service

[Service]
WorkingDirectory=%h/etherpad-lite
Environment="NODE_ENV=production"
Environment="BIND=127.0.0.1"
Environment="PATH=/home/pacs/xyz00/users/tools_pad/.nvm/versions/node/v20.18.3/bin:/usr/local/bin:/usr/bin:/bin"
ExecStart=%h/.nvm/versions/node/v20.18.3/bin/pnpm run prod

[Install]
WantedBy=default.target

#~/doms/pad.example.com/.htaccess
DirectoryIndex disabled
RewriteBase /
RewriteCond %{HTTP:Connection} Upgrade [NC]
RewriteCond %{HTTP:Upgrade} websocket [NC]
RewriteRule .* ws://localhost:9001%{REQUEST_URI} [proxy]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule .* http://localhost:9001%{REQUEST_URI} [proxy]

Wichtig ist, dass auf 127.0.0.1 ge-binded wird, und nicht die von Welt erreichbare Adresse 0.0.0.0. Man beachte das im Systemd Service File die node version hardcoded wird und beim Update zwei mal entsprechend angepasst werden muss. Genauso der User und der Paketusername, der leider nicht direkt ersetzt werden kann.

Dass auch nach Neustart der Etherpad Server erreichbar ist:

systemctl --user enable etherpad-lite

== v1: Konfiguration für Apache und Passenger ==

Vor der Nutzung von [[Phusion Passenger]] bitte unbedingt die dortigen Hinweise zur Nutzung beachten.

Die statischen Dateien der Anwendung werden mit den folgenden Befehlen richtig verlinkt
(immer noch als User ''xyz00-pad''):

<syntaxhighlight lang=shell>
cd
cd ~/doms/pad.example.com
rm -rf subs/www
rm -rf subs-ssl/www
rm -rf htdocs-ssl
ln -s ~/etherpad-lite/src/static htdocs-ssl
</syntaxhighlight>

Für die Anwendung legen wir im Verzeichnis ''~/doms/pad.example.com/app-ssl/'' eine Datei app.js mit dem folgenden Inhalt an:

<syntaxhighlight lang=javascript>
require('/home/pacs/xyz00/users/pad/etherpad-lite/node_modules/ep_etherpad-lite/node/server.js');
process.chdir('/home/pacs/xyz00/users/pad/etherpad-lite');
</syntaxhighlight>

Zum Schluß wird in der Datei ''~/etherpad-lite/settings.js'' noch die MySQL-Datenbank konfiguriert. Dazu muss der Teil mit ''dbType: mysql'' aktiv (nicht auskommentiert) sein. Etwa wie folgt:

<syntaxhighlight lang=javascript>
"dbType" : "mysql",
"dbSettings" : {
"user" : "xyz00_padusr",
"host" : "localhost",
"password": "anderes-Geheimwort",
"database": "xyz00_paddb",
"charset" : "utf8mb4",
"insecureAuth": "true"
},
</syntaxhighlight>

Die Einstellungen für den ''dbType: dirty'' werden dafür entfernt.

Weiter unten in der Datei kann dann noch ein Admin-User aktiviert werden.

Etherpad sollte nun unter der URL: ''http://pad.example.com/'' erreichbar sein.

== Update ==

Etherpad ist sehr pflegeleicht was das Update angeht. Es muss nur die neue Version in Git ausgecheckt werden und ./bin/run.sh erneut (einmalig) ausgeführt werden, damit die dependencies wieder neu gebaut werden. Auch von v1 -> v2 ist sonst nichts weiter zu tun.

== Links ==

*[http://etherpad.org/ Etherpad Homepage (Englisch)]
*[https://github.com/ether/etherpad-lite/ Github Repository (Englisch)]
*[https://github.com/ether/etherpad-lite/wiki/Running-Etherpad-on-Phusion-Passenger Running Etherpad on Phusion Passenger (Englisch)]

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Passenger]]
[[Kategorie:NodeJS]]

NodeJS

2025-03-05T23:17:51Z

Opa00-hostsharing: /* Installation von nvm */

== Eigene NodeJS Installation ==

Die JavaScript-Umgebung NodeJS für das Ausführen von JavaScript auf dem Server unterliegt noch einer rasanten Entwicklung.
Daher ist die Debian-Version, die bei Hostsharing vorinstalliert ist, oft zu alt für aktuelle Software.

Ein kurze Anleitung für die eigene NodeJS-Installation für einen User.

=== Installation von nvm ===

Die aktuellste Version von nvm kann wie folgt heruntergeladen werden:

<syntaxhighlight lang="shell">
touch ~/.profile
chmod u+x ~/.profile
cd /tmp
wget https://raw.githubusercontent.com/nvm-sh/nvm/refs/heads/master/install.sh
chmod u+x install.sh
./install.sh
</syntaxhighlight>

An dieser Stelle ab- und wieder anmelden oder die Befehle ausführen:

<syntaxhighlight lang="shell">
export NVM_DIR="/home/pacs/xyz00/users/example/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"
</syntaxhighlight>

Bitte auf die bei der Installation ausgegebenen Zeilen am Ende achten,
denn neuere nvm-Versionen benötigen ggf. etwas andere Schritte zur sofortigen Aktivierung.

=== Installation von NodeJS ===

<syntaxhighlight lang="shell">
nvm install 18
nvm alias default 18
</syntaxhighlight>

installiert (zum Beispiel) sehr einfach NodeJS in der Version 18.x.

analog für die Version 20.x:

<syntaxhighlight lang="shell">
nvm install 20
nvm alias default 20
</syntaxhighlight>

Aktuelle Versionen und LTS Versionen sind hier zu finden: https://nodejs.org/en/download/releases

==== Überprüfung der Installation ====

Der Befehl

<syntaxhighlight lang="shell">
node -v
</syntaxhighlight>

gibt die Version des aktiven NodeJS aus.

=== NodeJS Web-Applikation ===

Zur Integration der eigenen NodeJS-Installation in den Apache erfolgt über das Apache-Modul "Passenger".
Vor der Nutzung dieses Moduls bitte unbedingt die
[[Phusion Passenger|Hinweise zur Nutzung beachten]].

Den Pfad zum node-Binärprogramm konfiguriert man in einer ".htaccess"-Datei im
Verzeichnis der Domain "/home/pacs/xyz00/users/example/doms/example.com/.htaccess":

<syntaxhighlight lang="apache" line>
PassengerNodejs /home/pacs/xyz00/users/example/.nvm/versions/node/v16.14.2/bin/node
</syntaxhighlight>

(Versionsnummer, User und Paket im Pfad anpassen)

Für's Debugging ist die zusätzlich Option

<syntaxhighlight lang="apache" line>
PassengerFriendlyErrorPages On
</syntaxhighlight>

hilfreich.

Zum Testen kann man eine "app.js" ins Verzeichnis "/home/pacs/xyz00/users/example/doms/example.com/app-ssl/"
ablegen.

Eine minimale "app.js" zur Anzeige der NodeJS Version:

<syntaxhighlight lang="javascript" line>
var http = require("http");
http.createServer(function (request, response) {
response.writeHead(200, {'Content-Type': 'text/plain'});
response.write('node version ' + process.version + '\n');
response.end();
}).listen(3000);
</syntaxhighlight>

Um diese App zu deaktivieren, muss die Datei gelöscht werden.
Es reicht nicht aus, eine etwaige Konfiguration aus der .htaccess zu entfernen.

=== Weitere Installationen ===

Mit dem "Node Package Manager" npm läßt sich weitere Software in die Node-Umgebung installieren:

<syntaxhighlight lang="shell">
npm install -g gulp
npm install -g yarn
</syntaxhighlight>

----
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Passenger]]
[[Kategorie:NodeJS]]

OpenProject installieren

2025-03-02T14:14:01Z

Opa00-hostsharing: /* Upgrade durchführen */

== Allgemein ==
OpenProject ist eine umfangreiche Projektmanagement-Software. Die Software ist multiprojektfähig; für jedes Projekt stehen unter anderem folgende Werkzeuge zur Verfügung:
* Wiki
* Vorgangsverfolgung (Ticketsystem, Issue Tracker)
* Zeiterfassung
* Dokument- und Dateiverwaltung

Diese Anleitung beschreibt, wie man OpenProject auf der Managed Hosting Plattform von Hostsharing installieren kann. OpenProject lässt sich in jedem Managed Webspace betreiben.

Die Anleitung wurde für OpenProject Version 11 erstellt.

== Ansible Skript ==

Alternativ zur manuellen Installation, die in diesem Wiki Artikel beschrieben wird, gibt es ein
Ansible Skript, das die Installationsschritte für OpenProject automatisiert durchführt.

Die Quellen für das Ansible Skript können hier eingesehen werden: https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/openproject

== Vorbereitungen ==

=== Service-User, Domain und Datenbank ===

Mit Hilfe von HSAdmin werden angelegt:
# Ein User als Service-User mit ''/bin/bash'' als Shell, zum Beispiel Beispiel: ''xyz00-project"
# Eine Domain mit ''xyz00-project'' als Domain-Administrator, zum Beispiel "prj.example.com"
# Einen Postgresql-User ''xyz00_dbuser'' mit Passwort ''meinPasswort''
# Eine Postgresql-Datenbank ''xyz00_prjdb'' mit Datenbank-Owner ''xyz00_dbuser''

=== Vorbereitung des Webspace ===

Die "leichtgewichtige" Subdomain "www" wird gelöscht. Ebenso die ''.htaccess''-Datei mit der Weiterleitung dorthin.

<syntaxhighlight lang="bash">
xyz00@h20 $ sudo -u xyz00-project -i
xyz00-project@h20:~$ cd ~/doms/projekt.example.com/
xyz00-project@h20:~/doms/projekt.example.com$ rm -rf subs/www/ subs-ssl/www/ htdocs-ssl/.htaccess
</syntaxhighlight>

=== Installation von Ruby ===

Weiterhin benötigt OpenProject eine geeignete Version der Programmiersprache Ruby.

Die gewünschte Version kann hier abgelesen werden: https://github.com/opf/openproject/blob/stable/11/.ruby-version

Die Installation-Anleitung für OpenProject schlägt für die Installation ''rbenv'' vor.

<syntaxhighlight lang="bash">
xyz00-project@h20:~/doms/projekt.example.com$ cd
xyz00-project@h20:~$ git clone https://github.com/sstephenson/rbenv.git ~/.rbenv
xyz00-project@h20:~$ touch .profile
xyz00-project@h20:~$ chmod u+x .profile
xyz00-project@h20:~$ echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.profile
xyz00-project@h20:~$ echo 'eval "$(rbenv init -)"' >> ~/.profile
xyz00-project@h20:~$ source ~/.profile
xyz00-project@h20:~$ git clone https://github.com/sstephenson/ruby-build.git ~/.rbenv/plugins/ruby-build
xyz00-project@h20:~$ rbenv install 2.7.4
xyz00-project@h20:~$ rbenv rehash
xyz00-project@h20:~$ rbenv global 2.7.4
</syntaxhighlight>

Als Test bitte aufrufen: ''ruby -v''

Die Anzeige sollte etwa das Folgende enthalten:
ruby 2.7.4pXYZ (....) [x86_64-linux]

=== Installation von Node ===

Die Installation-Anleitung für OpenProject schlägt für die Installation ''nodenv'' vor.

<syntaxhighlight lang="bash">
xyz00-project@h20:~$ git clone https://github.com/OiNutter/nodenv.git ~/.nodenv
xyz00-project@h20:~$ echo 'export PATH="$HOME/.nodenv/bin:$PATH"' >> ~/.profile
xyz00-project@h20:~$ echo 'eval "$(nodenv init -)"' >> ~/.profile
xyz00-project@h20:~$ source ~/.profile
xyz00-project@h20:~$ git clone git://github.com/OiNutter/node-build.git ~/.nodenv/plugins/node-build
xyz00-project@h20:~$ nodenv install 12.18.4
xyz00-project@h20:~$ nodenv rehash
xyz00-project@h20:~$ nodenv global 12.18.4
</syntaxhighlight>

Ein Test mit ''node --version'' solte anzeigen: v12.18.4

== Installation und Konfiguration ==

=== Installation von OpenProject ===

Wir installieren die OpenProject Community Edition. siehe https://github.com/opf/openproject

<syntaxhighlight lang="bash">
xyz00-project@h20:~$ git clone https://github.com/opf/openproject.git --branch stable/11 --depth 1
xyz00-project@h20:~$ cd ~/openproject
xyz00-project@h20:~$ gem update --system
xyz00-project@h20:~$ gem install bundler
xyz00-project@h20:~$ bundle update --bundler
xyz00-project@h20:~$ bundle config set deployment 'true'
xyz00-project@h20:~$ bundle config set without 'mysql2 sqlite development test therubyracer docker'
xyz00-project@h20:~$ bundle install
xyz00-project@h20:~$ npm install
</syntaxhighlight>

=== Konfiguration von OpenProject ===

Erstelle eine Konfiguration für den Datenbank-Zugriff in der Datei ''config/database.yml''

<syntaxhighlight lang="bash">
xyz00-project@h20:~$ cd ~/openproject
xyz00-project@h20:~/openproject$ cp config/database.yml.example config/database.yml
</syntaxhighlight>

In der neuen Datei ''database.yml'' wird die mit HSAdmin angelegte PostgreSQL-Datenbank eingetragen:
<syntaxhighlight lang="yaml" line>
production:
adapter: postgresql
encoding: unicode
host: localhost
database: xyz00_prjdb (wie oben angegeben)
pool: 10
username: xyz00_dbuser (wie oben angegeben)
password: meinPasswort (wie oben angegeben)
</syntaxhighlight>

Die Einträge für ''development'' und ''test'' können gelöscht werden.

Dann wird die Datei ''configuration.yml'' angelegt:

<syntaxhighlight lang="yaml" line>
xyz00-project@h20:~$ cd ~/openproject
xyz00-project@h20:~/openproject$ cp config/configuration.yml.example config/configuration.yml
</syntaxhighlight>

Dort erfolgen die Einstellungen für ausgehende E-Mails:

<syntaxhighlight lang="yaml" line>
default:
log_level: info
email_delivery_method: :smtp
smtp_address: localhost
smtp_port: 25
smtp_domain: example.com
#smtp_authentication: :login
#smtp_user_name: "openproject@example.net"
#smtp_password: "my_openproject_password"
</syntaxhighlight>

Die Zeilen mit smtp_authentication, smtp_user_name und smtp_password können auskommentiert werden, sie werden in unserem Setup nicht benötigt.

Es muss außerdem vermieden werden, dass beim Hochladen von Dateien in /tmp geschrieben wird. Dazu wird das Verzeichnis $HOME/var/tmp angelegt, und die Datei <code>openproject/config/initializers/tmpdir.rb</code> mit folgendem Inhalt erstellt:

<syntaxhighlight lang="ruby" line>
class Dir
def self.tmpdir
"/home/pacs/xyz00/users/project/var/tmp/"
end
end
</syntaxhighlight>

=== Einen geheimen Schlüssel erzeugen ===

<syntaxhighlight lang=bash>
xyz00-project@h20:~$ cd ~/openproject
xyz00-project@h20:~/openproject$ EDITOR=cat ./bin/rails credentials:edit
</syntaxhighlight>

=== Initialisiere Datenbank und erzeuge Web-Ressourcen ===

<syntaxhighlight lang=bash>
xyz00-project@h20:~$ cd ~/openproject
xyz00-project@h20:~/openproject$ export RAILS_ENV="production"
xyz00-project@h20:~/openproject$ source ~/.profile
xyz00-project@h20:~/openproject$ ./bin/rails db:prepare
xyz00-project@h20:~/openproject$ ./bin/rake assets:precompile
</syntaxhighlight>

=== Anlegen des Administrators ===

Es kann eine Demo Installation installiert werden:
<syntaxhighlight lang=bash>
xyz00-project@h20:~$ cd ~/openproject
xyz00-project@h20:~/openproject$ export RAILS_ENV="production"
xyz00-project@h20:~/openproject$ source ~/.profile
xyz00-project@h20:~/openproject$ LOCALE=en ./bin/rake db:seed
</syntaxhighlight>

Damit wird ein Beispiel-Projekt angelegt, das man wieder löschen kann.

Wichtig ist aber, dass der Benutzer <code>admin</code> mit dem Passwort <code>admin</code> angelegt wird. Das Passwort muss bei der ersten Anmeldung geändert werden.

=== Konfiguration in Passenger ===

<syntaxhighlight lang=bash>
xyz00-project@h20:~$ cd ~/doms/prj.example.com
xyz00-project@h20:~/doms/prj.example.com$ rm -rf app-ssl htdocs-ssl
xyz00-project@h20:~/doms/prj.example.com$ ln -s $HOME/openproject app-ssl
xyz00-project@h20:~/doms/prj.example.com$ ln -s $HOME/openproject/public htdocs-ssl
</syntaxhighlight>

Weiterhin muss in einer .htaccess-Datei in diesem Verzeichnis die richtige Umgebung gesetzt sein:

<syntaxhighlight lang=apache>
# xyz00-project@h20:~/doms/prj.example.com$ cat .htaccess

SetEnv OPENPROJECT_STORAGE_TMP__PATH /home/pacs/xyz00/users/project/var/tmp/
SetEnv TMPDIR /home/pacs/xyz00/users/project/var/tmp/
PassengerRuby /home/pacs/xyz00/users/project/.rbenv/shims/ruby
</syntaxhighlight>

== Aufsetzen des systemd Timers für Hintergrundprozesse ==

Es werden Benachrichtigungs-E-Mails im Hintergrund verschickt. Dazu muss ein Prozess im Hintergrund gestartet werden. Um Probleme zu vermeiden, dass source nicht zur Verfügung steht, kann der Aufruf in einer eigenen Skriptdatei geschehen, die zwingend mit Bash ausgeführt wird, wo source verfügbar ist.

Datei ''/home/pacs/xyz00/users/project/emailjob.sh'':

<syntaxhighlight lang=bash line>
#!/bin/bash
source ~/.profile
cd ~/openproject
RAILS_ENV="production" ./bin/rake jobs:workoff
</syntaxhighlight>

Datei ''/home/pacs/xyz00/users/project/jobrestart.sh'':

<syntaxhighlight lang=bash line>
#!/bin/bash
source ~/.profile
cd ~/openproject
RAILS_ENV="production" ./bin/delayed_job restart
</syntaxhighlight>

Nun können die Timer eingerichtet werden:

''~/.config/systemd/user/openproject_emails.service''
<syntaxhighlight lang=ini line>
[Unit]
Description=openproject mails

[Service]
Type=oneshot
ExecStart=/home/pacs/xyz00/users/project/emailjob.sh
</syntaxhighlight>

~/.config/systemd/user/openproject_emails.timer
<syntaxhighlight lang=ini line>
[Unit]
Description=openproject mails

[Timer]
OnCalendar=*:0/2
Persistent=True

[Install]
WantedBy=timers.target
</syntaxhighlight>

Damit wird der Hintergrundprozess alle 2 Minuten gestartet.

Es gibt noch einen Hintergrundjob, den ich einmal in der Stunde neu starte:

''~/.config/systemd/user/openproject_jobrestart.service''
<syntaxhighlight lang=ini line>
[Unit]
Description=openproject restart job

[Service]
Type=oneshot
ExecStart=/home/pacs/xyz00/users/project/jobrestart.sh
</syntaxhighlight>

~/.config/systemd/user/openproject_jobrestart.timer
<syntaxhighlight lang=ini line>
[Unit]
Description=openproject restart job

[Timer]
OnCalendar=*:22
Persistent=True

[Install]
WantedBy=timers.target
</syntaxhighlight>

Timer aktivieren und starten:
<syntaxhighlight lang=bash line>
$ systemctl --user enable openproject_emails.timer
$ systemctl --user start openproject_emails.timer
$ systemctl --user enable openproject_jobrestart.timer
$ systemctl --user start openproject_jobrestart.timer
</syntaxhighlight>

== Upgrade durchführen ==

Die gewünschte Ruby Version kann hier abgelesen werden (ggf. Branch passend wechseln): https://github.com/opf/openproject/blob/stable/11/.ruby-version

Die benötigte Nodejs Version kann im git repository in der package.json unter engine abgelesen werden.

Für das Upgrade von OpenProject 11.2.4 auf 11.3.4, musste eine neue Version von Ruby installiert werden:

<syntaxhighlight lang=bash>
xyz00-project@h20:~$ cd ~/openproject
xyz00-project@h20:~/openproject$ source ~/.profile
xyz00-project@h20:~/openproject$ git -C $HOME/.rbenv/plugins/ruby-build pull
xyz00-project@h20:~/openproject$ rbenv install 2.7.4
xyz00-project@h20:~/openproject$ rbenv rehash
xyz00-project@h20:~/openproject$ rbenv global 2.7.4
xyz00-project@h20:~/openproject$ source ~/.profile
xyz00-project@h20:~/openproject$ rm -Rf $HOME/.rbenv/versions/2.7.3/ # alte Version kann gelöscht werden
</syntaxhighlight>

Weil das Git Repository bei der Erstinstallation nur einen Branch enthielt, muss nun das Repository passend nachgeladen werden (Beispielhaft für den Branch stable/15)

<syntaxhighlight lang=bash>
xyz00-project@h20:~$ cd openproject
xyz00-project@h20:~/openproject$ source ~/.profile
xyz00-project@h20:~/openproject$ git remote set-branches --add origin stable/15
xyz00-project@h20:~/openproject$ git fetch
xyz00-project@h20:~/openproject$ git checkout stable/15
</syntaxhighlight>

Nach Verifikation dass das update erfolgreich war, kann der alte Branch gelöscht werden, nach bedarf mit:

<syntaxhighlight lang=bash>
xyz00-project@h20:~$ git branch -D old_branch_name
</syntaxhighlight>

Generell müssen diese Schritte durchgeführt werden:

<syntaxhighlight lang=bash>
xyz00-project@h20:~$ cd openproject
xyz00-project@h20:~/openproject$ source ~/.profile
xyz00-project@h20:~/openproject$ git fetch
xyz00-project@h20:~/openproject$ git pull
xyz00-project@h20:~/openproject$ gem update --system
xyz00-project@h20:~/openproject$ bundle install
xyz00-project@h20:~/openproject$ npm install
xyz00-project@h20:~/openproject$ export RAILS_ENV="production"
xyz00-project@h20:~/openproject$ ./bin/rake db:migrate
xyz00-project@h20:~/openproject$ ./bin/rake assets:precompile
xyz00-project@h20:~/openproject$ touch ~/doms/prj.example.com/app-ssl/tmp/restart.txt
</syntaxhighlight>

== Referenzen ==

* [https://docs.openproject.org/installation-and-operations/installation/manual/ Anleitung für die manuelle Installation]
* [https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/openproject Ansible Playbook für Hostsharing]
----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:Software]]
[[Kategorie:RubyOnRails]]
[[Kategorie:Passenger]]
[[Kategorie:Projektmanagement]]
[[Kategorie:Projektverwaltung]]

OpenProject installieren

2025-03-02T14:10:47Z

Opa00-hostsharing:

== Allgemein ==
OpenProject ist eine umfangreiche Projektmanagement-Software. Die Software ist multiprojektfähig; für jedes Projekt stehen unter anderem folgende Werkzeuge zur Verfügung:
* Wiki
* Vorgangsverfolgung (Ticketsystem, Issue Tracker)
* Zeiterfassung
* Dokument- und Dateiverwaltung

Diese Anleitung beschreibt, wie man OpenProject auf der Managed Hosting Plattform von Hostsharing installieren kann. OpenProject lässt sich in jedem Managed Webspace betreiben.

Die Anleitung wurde für OpenProject Version 11 erstellt.

== Ansible Skript ==

Alternativ zur manuellen Installation, die in diesem Wiki Artikel beschrieben wird, gibt es ein
Ansible Skript, das die Installationsschritte für OpenProject automatisiert durchführt.

Die Quellen für das Ansible Skript können hier eingesehen werden: https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/openproject

== Vorbereitungen ==

=== Service-User, Domain und Datenbank ===

Mit Hilfe von HSAdmin werden angelegt:
# Ein User als Service-User mit ''/bin/bash'' als Shell, zum Beispiel Beispiel: ''xyz00-project"
# Eine Domain mit ''xyz00-project'' als Domain-Administrator, zum Beispiel "prj.example.com"
# Einen Postgresql-User ''xyz00_dbuser'' mit Passwort ''meinPasswort''
# Eine Postgresql-Datenbank ''xyz00_prjdb'' mit Datenbank-Owner ''xyz00_dbuser''

=== Vorbereitung des Webspace ===

Die "leichtgewichtige" Subdomain "www" wird gelöscht. Ebenso die ''.htaccess''-Datei mit der Weiterleitung dorthin.

<syntaxhighlight lang="bash">
xyz00@h20 $ sudo -u xyz00-project -i
xyz00-project@h20:~$ cd ~/doms/projekt.example.com/
xyz00-project@h20:~/doms/projekt.example.com$ rm -rf subs/www/ subs-ssl/www/ htdocs-ssl/.htaccess
</syntaxhighlight>

=== Installation von Ruby ===

Weiterhin benötigt OpenProject eine geeignete Version der Programmiersprache Ruby.

Die gewünschte Version kann hier abgelesen werden: https://github.com/opf/openproject/blob/stable/11/.ruby-version

Die Installation-Anleitung für OpenProject schlägt für die Installation ''rbenv'' vor.

<syntaxhighlight lang="bash">
xyz00-project@h20:~/doms/projekt.example.com$ cd
xyz00-project@h20:~$ git clone https://github.com/sstephenson/rbenv.git ~/.rbenv
xyz00-project@h20:~$ touch .profile
xyz00-project@h20:~$ chmod u+x .profile
xyz00-project@h20:~$ echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.profile
xyz00-project@h20:~$ echo 'eval "$(rbenv init -)"' >> ~/.profile
xyz00-project@h20:~$ source ~/.profile
xyz00-project@h20:~$ git clone https://github.com/sstephenson/ruby-build.git ~/.rbenv/plugins/ruby-build
xyz00-project@h20:~$ rbenv install 2.7.4
xyz00-project@h20:~$ rbenv rehash
xyz00-project@h20:~$ rbenv global 2.7.4
</syntaxhighlight>

Als Test bitte aufrufen: ''ruby -v''

Die Anzeige sollte etwa das Folgende enthalten:
ruby 2.7.4pXYZ (....) [x86_64-linux]

=== Installation von Node ===

Die Installation-Anleitung für OpenProject schlägt für die Installation ''nodenv'' vor.

<syntaxhighlight lang="bash">
xyz00-project@h20:~$ git clone https://github.com/OiNutter/nodenv.git ~/.nodenv
xyz00-project@h20:~$ echo 'export PATH="$HOME/.nodenv/bin:$PATH"' >> ~/.profile
xyz00-project@h20:~$ echo 'eval "$(nodenv init -)"' >> ~/.profile
xyz00-project@h20:~$ source ~/.profile
xyz00-project@h20:~$ git clone git://github.com/OiNutter/node-build.git ~/.nodenv/plugins/node-build
xyz00-project@h20:~$ nodenv install 12.18.4
xyz00-project@h20:~$ nodenv rehash
xyz00-project@h20:~$ nodenv global 12.18.4
</syntaxhighlight>

Ein Test mit ''node --version'' solte anzeigen: v12.18.4

== Installation und Konfiguration ==

=== Installation von OpenProject ===

Wir installieren die OpenProject Community Edition. siehe https://github.com/opf/openproject

<syntaxhighlight lang="bash">
xyz00-project@h20:~$ git clone https://github.com/opf/openproject.git --branch stable/11 --depth 1
xyz00-project@h20:~$ cd ~/openproject
xyz00-project@h20:~$ gem update --system
xyz00-project@h20:~$ gem install bundler
xyz00-project@h20:~$ bundle update --bundler
xyz00-project@h20:~$ bundle config set deployment 'true'
xyz00-project@h20:~$ bundle config set without 'mysql2 sqlite development test therubyracer docker'
xyz00-project@h20:~$ bundle install
xyz00-project@h20:~$ npm install
</syntaxhighlight>

=== Konfiguration von OpenProject ===

Erstelle eine Konfiguration für den Datenbank-Zugriff in der Datei ''config/database.yml''

<syntaxhighlight lang="bash">
xyz00-project@h20:~$ cd ~/openproject
xyz00-project@h20:~/openproject$ cp config/database.yml.example config/database.yml
</syntaxhighlight>

In der neuen Datei ''database.yml'' wird die mit HSAdmin angelegte PostgreSQL-Datenbank eingetragen:
<syntaxhighlight lang="yaml" line>
production:
adapter: postgresql
encoding: unicode
host: localhost
database: xyz00_prjdb (wie oben angegeben)
pool: 10
username: xyz00_dbuser (wie oben angegeben)
password: meinPasswort (wie oben angegeben)
</syntaxhighlight>

Die Einträge für ''development'' und ''test'' können gelöscht werden.

Dann wird die Datei ''configuration.yml'' angelegt:

<syntaxhighlight lang="yaml" line>
xyz00-project@h20:~$ cd ~/openproject
xyz00-project@h20:~/openproject$ cp config/configuration.yml.example config/configuration.yml
</syntaxhighlight>

Dort erfolgen die Einstellungen für ausgehende E-Mails:

<syntaxhighlight lang="yaml" line>
default:
log_level: info
email_delivery_method: :smtp
smtp_address: localhost
smtp_port: 25
smtp_domain: example.com
#smtp_authentication: :login
#smtp_user_name: "openproject@example.net"
#smtp_password: "my_openproject_password"
</syntaxhighlight>

Die Zeilen mit smtp_authentication, smtp_user_name und smtp_password können auskommentiert werden, sie werden in unserem Setup nicht benötigt.

Es muss außerdem vermieden werden, dass beim Hochladen von Dateien in /tmp geschrieben wird. Dazu wird das Verzeichnis $HOME/var/tmp angelegt, und die Datei <code>openproject/config/initializers/tmpdir.rb</code> mit folgendem Inhalt erstellt:

<syntaxhighlight lang="ruby" line>
class Dir
def self.tmpdir
"/home/pacs/xyz00/users/project/var/tmp/"
end
end
</syntaxhighlight>

=== Einen geheimen Schlüssel erzeugen ===

<syntaxhighlight lang=bash>
xyz00-project@h20:~$ cd ~/openproject
xyz00-project@h20:~/openproject$ EDITOR=cat ./bin/rails credentials:edit
</syntaxhighlight>

=== Initialisiere Datenbank und erzeuge Web-Ressourcen ===

<syntaxhighlight lang=bash>
xyz00-project@h20:~$ cd ~/openproject
xyz00-project@h20:~/openproject$ export RAILS_ENV="production"
xyz00-project@h20:~/openproject$ source ~/.profile
xyz00-project@h20:~/openproject$ ./bin/rails db:prepare
xyz00-project@h20:~/openproject$ ./bin/rake assets:precompile
</syntaxhighlight>

=== Anlegen des Administrators ===

Es kann eine Demo Installation installiert werden:
<syntaxhighlight lang=bash>
xyz00-project@h20:~$ cd ~/openproject
xyz00-project@h20:~/openproject$ export RAILS_ENV="production"
xyz00-project@h20:~/openproject$ source ~/.profile
xyz00-project@h20:~/openproject$ LOCALE=en ./bin/rake db:seed
</syntaxhighlight>

Damit wird ein Beispiel-Projekt angelegt, das man wieder löschen kann.

Wichtig ist aber, dass der Benutzer <code>admin</code> mit dem Passwort <code>admin</code> angelegt wird. Das Passwort muss bei der ersten Anmeldung geändert werden.

=== Konfiguration in Passenger ===

<syntaxhighlight lang=bash>
xyz00-project@h20:~$ cd ~/doms/prj.example.com
xyz00-project@h20:~/doms/prj.example.com$ rm -rf app-ssl htdocs-ssl
xyz00-project@h20:~/doms/prj.example.com$ ln -s $HOME/openproject app-ssl
xyz00-project@h20:~/doms/prj.example.com$ ln -s $HOME/openproject/public htdocs-ssl
</syntaxhighlight>

Weiterhin muss in einer .htaccess-Datei in diesem Verzeichnis die richtige Umgebung gesetzt sein:

<syntaxhighlight lang=apache>
# xyz00-project@h20:~/doms/prj.example.com$ cat .htaccess

SetEnv OPENPROJECT_STORAGE_TMP__PATH /home/pacs/xyz00/users/project/var/tmp/
SetEnv TMPDIR /home/pacs/xyz00/users/project/var/tmp/
PassengerRuby /home/pacs/xyz00/users/project/.rbenv/shims/ruby
</syntaxhighlight>

== Aufsetzen des systemd Timers für Hintergrundprozesse ==

Es werden Benachrichtigungs-E-Mails im Hintergrund verschickt. Dazu muss ein Prozess im Hintergrund gestartet werden. Um Probleme zu vermeiden, dass source nicht zur Verfügung steht, kann der Aufruf in einer eigenen Skriptdatei geschehen, die zwingend mit Bash ausgeführt wird, wo source verfügbar ist.

Datei ''/home/pacs/xyz00/users/project/emailjob.sh'':

<syntaxhighlight lang=bash line>
#!/bin/bash
source ~/.profile
cd ~/openproject
RAILS_ENV="production" ./bin/rake jobs:workoff
</syntaxhighlight>

Datei ''/home/pacs/xyz00/users/project/jobrestart.sh'':

<syntaxhighlight lang=bash line>
#!/bin/bash
source ~/.profile
cd ~/openproject
RAILS_ENV="production" ./bin/delayed_job restart
</syntaxhighlight>

Nun können die Timer eingerichtet werden:

''~/.config/systemd/user/openproject_emails.service''
<syntaxhighlight lang=ini line>
[Unit]
Description=openproject mails

[Service]
Type=oneshot
ExecStart=/home/pacs/xyz00/users/project/emailjob.sh
</syntaxhighlight>

~/.config/systemd/user/openproject_emails.timer
<syntaxhighlight lang=ini line>
[Unit]
Description=openproject mails

[Timer]
OnCalendar=*:0/2
Persistent=True

[Install]
WantedBy=timers.target
</syntaxhighlight>

Damit wird der Hintergrundprozess alle 2 Minuten gestartet.

Es gibt noch einen Hintergrundjob, den ich einmal in der Stunde neu starte:

''~/.config/systemd/user/openproject_jobrestart.service''
<syntaxhighlight lang=ini line>
[Unit]
Description=openproject restart job

[Service]
Type=oneshot
ExecStart=/home/pacs/xyz00/users/project/jobrestart.sh
</syntaxhighlight>

~/.config/systemd/user/openproject_jobrestart.timer
<syntaxhighlight lang=ini line>
[Unit]
Description=openproject restart job

[Timer]
OnCalendar=*:22
Persistent=True

[Install]
WantedBy=timers.target
</syntaxhighlight>

Timer aktivieren und starten:
<syntaxhighlight lang=bash line>
$ systemctl --user enable openproject_emails.timer
$ systemctl --user start openproject_emails.timer
$ systemctl --user enable openproject_jobrestart.timer
$ systemctl --user start openproject_jobrestart.timer
</syntaxhighlight>

== Upgrade durchführen ==

Die gewünschte Ruby Version kann hier abgelesen werden: https://github.com/opf/openproject/blob/stable/11/.ruby-version

Für das Upgrade von OpenProject 11.2.4 auf 11.3.4, musste eine neue Version von Ruby installiert werden:

<syntaxhighlight lang=bash>
xyz00-project@h20:~$ cd ~/openproject
xyz00-project@h20:~/openproject$ source ~/.profile
xyz00-project@h20:~/openproject$ git -C $HOME/.rbenv/plugins/ruby-build pull
xyz00-project@h20:~/openproject$ rbenv install 2.7.4
xyz00-project@h20:~/openproject$ rbenv rehash
xyz00-project@h20:~/openproject$ rbenv global 2.7.4
xyz00-project@h20:~/openproject$ source ~/.profile
xyz00-project@h20:~/openproject$ rm -Rf $HOME/.rbenv/versions/2.7.3/ # alte Version kann gelöscht werden
</syntaxhighlight>

Weil das Git Repository bei der Erstinstallation nur einen Branch enthielt, muss nun das Repository passend nachgeladen werden (Beispielhaft für den Branch stable/15)

<syntaxhighlight lang=bash>
xyz00-project@h20:~$ cd openproject
xyz00-project@h20:~/openproject$ source ~/.profile
xyz00-project@h20:~/openproject$ git remote set-branches --add origin stable/15
xyz00-project@h20:~/openproject$ git fetch
xyz00-project@h20:~/openproject$ git checkout stable/15
</syntaxhighlight>

Nach Verifikation dass das update erfolgreich war, kann der alte Branch gelöscht werden, nach bedarf mit:

<syntaxhighlight lang=bash>
xyz00-project@h20:~$ git branch -D old_branch_name
</syntaxhighlight>

Generell müssen diese Schritte durchgeführt werden:

<syntaxhighlight lang=bash>
xyz00-project@h20:~$ cd openproject
xyz00-project@h20:~/openproject$ source ~/.profile
xyz00-project@h20:~/openproject$ git fetch
xyz00-project@h20:~/openproject$ git pull
xyz00-project@h20:~/openproject$ gem update --system
xyz00-project@h20:~/openproject$ bundle install
xyz00-project@h20:~/openproject$ npm install
xyz00-project@h20:~/openproject$ export RAILS_ENV="production"
xyz00-project@h20:~/openproject$ ./bin/rake db:migrate
xyz00-project@h20:~/openproject$ ./bin/rake assets:precompile
xyz00-project@h20:~/openproject$ touch ~/doms/prj.example.com/app-ssl/tmp/restart.txt
</syntaxhighlight>

== Referenzen ==

* [https://docs.openproject.org/installation-and-operations/installation/manual/ Anleitung für die manuelle Installation]
* [https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/openproject Ansible Playbook für Hostsharing]
----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:Software]]
[[Kategorie:RubyOnRails]]
[[Kategorie:Passenger]]
[[Kategorie:Projektmanagement]]
[[Kategorie:Projektverwaltung]]

Zammad

2025-01-21T08:20:01Z

Opa00-hostsharing: /* Installation nodejs */

== Anforderungen ==
Zammad ist ein relativ umfangreiches, mächtiges und modernes OSS Helpdesk Tool. Für die Installation wird benötigt:

* eine (Sub)Domain
* 2 bis 4 GB RAM (Schätzung, eure Erfahrung kann abweichen, je nach Nutzung)
* ruby
* nodejs
* mehrere Daemons für Hintergrunddienste (worker, websocket)
* evtl. noch ElasticSearch für Volltextsuche

== Installation ==

Die Installation orientiert sich an dieser Anleitung und wurde für zammad 6.3 verfasst.
Einige HS spezifische Abweichungen gibt es jedoch.

* https://docs.zammad.org/en/latest/install/source.html

=== User anlegen ===
Für diese Anleitung wird angenommen das der User unter dem zammad laufen soll xyz00-zammad im Packet xyz00 ist.

=== Installation ruby / ruby env ===
Prüfe die Version von ruby die zammad benötigt [https://docs.zammad.org/en/latest/prerequisites/software.html#ruby-programming-language hier].

Für diese Anleitung nehmen wir Version 3.2.3 an für zammad 6.3.

Die Installationsanleitung für rubyenv und ruby findet sich unter [[RubyRBEnv]].

Verifiziere das die Installation geklappt hat mit
<syntaxhighlight lang=shell>
ruby -v
</syntaxhighlight>
dies sollte der herausgesuchten Versionsnummer entsprechen

=== Installation nodejs ===
Prüfe die Version von nodejs die zammad benötigt [https://docs.zammad.org/en/latest/prerequisites/software.html#node-js hier].

Für diese Anleitung nehmen wir Version 20 an für zammad 6.3.

Verifiziere das die Installation geklappt hat mit
<syntaxhighlight lang=shell>
node -v
</syntaxhighlight>
dies sollte der herausgesuchten Versionsnummer entsprechen

Hinweis: ab Zammad v6.4.1 wird mit pnpm gearbeitet

Ersteinrichtung von pnpm:

corepack enable pnpm

Installation der Zammad Packages

pnpm install

=== Installation Redis ===

Siehe [[Redis]]

=== Umgebungsvariablen ===

Meine `.profile`, `.bashrc`, `.bash_profile` sahen dann wie folgt aus (möglicherweise gibt es hier optimierungspotential)

Die Datei `.bash_profile`:
. ~/.profile
. ~/.bashrc
Die Datei `.profile` (vgl instalation ruby und nodejs):

<syntaxhighlight lang=shell line>
#ruby
export PATH="$HOME/.rbenv/bin:$PATH"
eval "$(rbenv init -)"
#nodejs
export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh" # This loads nvm
[ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion" # This loads nvm bash_completion
</syntaxhighlight>
und die Datei `.bashrc`. Quellen vgl. [https://github.com/zammad/zammad/tree/develop/script/systemd/zammad.env] und [https://docs.zammad.org/en/latest/appendix/configure-env-vars.html#performance-tuning]

<syntaxhighlight lang=shell>
export REDIS_URL=redis://:<your-password-goes-here>@127.0.0.1:<port>
export RAILS_ENV=production
</syntaxhighlight>

Dann entweder alles neu einlesen oder einmal aus und wieder einloggen. Wenn alles geklappt hat, sollten die folgenden Befehle alle sinnvolle Ausgaben liefern

<syntaxhighlight lang=shell>
echo $RAILS_ENV # Ausgabe: production
ruby -v # Ausgabe vgl. oben
nodejs -v # Ausgabe vgl. oben
</syntaxhighlight>

=== Installation von Zammad ===
Zuerst laden wir zammad herunter, entpacken es, und installieren die dependencies (nur production)

<syntaxhighlight lang=shell>
mkdir zammad
cd zammad
wget -O - https://ftp.zammad.com/zammad-latest.tar.gz |tar -xvvz
bundle config set --local without 'test development mysql'
bundle install
</syntaxhighlight>

Dann tragen wir die zugangsdaten der postgres Datenbank ein (auf HS Admin selbst erstellen) hier: beides `xyz00_zammad`
Mit folgendem Inhalt (Einrückung beachten!):

<syntaxhighlight lang=yaml line>
# nano config/database.yml

# config/database.yml
production:
adapter: postgresql
host: localhost
database: xyz00_zammad
pool: 50
timeout: 5000
encoding: utf8
username: xyz00_zammad
password: changeme
</syntaxhighlight>

Wenn alles stimmt sollten sich die folgenden Befehle ohne Fehler ausführen lassen und die Datenbanktabellen sowie die statischen Dateien zum ausliefern anlegen

<syntaxhighlight lang=shell>
rake db:migrate
rake assets:precompile
</syntaxhighlight>

=== Zammad ausliefern ===
Um via Browser auf zammad zugreifen zu können kann es via [[Phusion Passenger]] ausgeliefert werden. Dazu muss im HS Admin eine Domain aufgeschaltet werden. Dann wird:
* die .htaccess wie folgend gesetzt werden
* der zammad ordner nach app-ssl gelinkt werden
* und der statische content in htdocs-ssl
* Optional kann das Domain Template noch um die subdomains bereinigt werden (2. Befehl)

<syntaxhighlight lang=shell>
cd ~/doms/zammad.example.org/
rm -r subs*
rm -r htdocs-ssl
rm -r app-ssl
ln -s ~/zammad app-ssl
ln -s ~/zammad/public htdocs-ssl
nano .htaccess
</syntaxhighlight>

In HS-Admin muss unter der Domain dann folgende Eigenschaft bei Passenger gesetzt werden:

<syntaxhighlight lang=apache>
PassengerRuby /home/pacs/xyz00/users/zammad/.rbenv/shims/ruby
</syntaxhighlight>

<syntaxhighlight lang=apache>
# Inhalt .htaccess
DirectoryIndex disabled
RewriteEngine On
RewriteBase /

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{HTTP:Connection} Upgrade [NC]
RewriteCond %{HTTP:Upgrade} websocket [NC]
RewriteRule .* ws://127.0.0.1:6042/%{REQUEST_URI} [P,L]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RequestHeader set X-Forwarded-Proto "https"
RewriteRule .* http://127.0.0.1:6041/%{REQUEST_URI} [proxy,last]
</syntaxhighlight>

Wenn alles geklappt hat sollte auf der Domain das restliche Web-basierte Setup zu sehen sein. Dort muss dann auch der andere HS Postfach User eingetragen werden. Theoretisch könnte man das auf dem gleichen Account abwickeln, ich persönlich würde es allerdings trennen. Piping wie bei manch andren Mailbasierten Anwendungen scheint nicht so einfach möglich zu sein (needs more investigation)

=== Hintergrunddienste ===

Damit der Websocket-Server und der Hintergrund Worker ordentlich laufen müssen folgende Befehle ausgeführt werden. Die IP Adresse und der Port beim Socket werden aus den Enviroment Variablen von oben bezogen, können allerdings auch manuell gesetzt werden.

<syntaxhighlight lang=shell>
cd zammad
bundle exec script/background-worker.rb start
bundle exec script/websocket-server.rb -b ${ZAMMAD_BIND_IP} -p ${ZAMMAD_WEBSOCKET_PORT} start
</syntaxhighlight>

== Empfohlen: Monit ==
Ich habe alles monit spezifische in den ordner monit gepackt

<syntaxhighlight lang=shell>
cd
mkdir monit
cd monit
</syntaxhighlight>

Zum starten habe ich ein kleines start und stop script (für monit) erstellt (lange zeile ggf. beachten)

<syntaxhighlight lang=shell line>
# nano start-worker.sh

#!/bin/bash
. ~/.bash_profile
cd ~/zammad
exec ${BUNDLE_BINARY} exec script/background-worker.rb start > ~/monit/worker.log 2>&1 &
echo $! > ~/monit/worker.pid
</syntaxhighlight>

<syntaxhighlight lang=shell line>
# nano start-websocket.sh

#!/bin/bash
. ~/.bash_profile
cd ~/zammad
# warnung, der socket produziert relativ viel log output im normalen Betrieb ggf. anpassen
exec ${BUNDLE_BINARY} exec script/websocket-server.rb -b ${ZAMMAD_BIND_IP} -p ${ZAMMAD_WEBSOCKET_PORT} start > ~/monit/socket.log 2>&1 &
echo $! > ~/monit/socket.pid
</syntaxhighlight>

<syntaxhighlight lang=shell line>
# nano stop-worker.sh

kill $( cat ~/monit/worker.pid )
</syntaxhighlight>

<syntaxhighlight lang=shell line>
# nano stop-websocket.sh

kill $( cat ~/monit/socket.pid )
</syntaxhighlight>

Das dann alles noch in der `~/.monitrc` zusammenführen (achtung einige xyz00, zammad (user) und Mail Platzhalter):

<syntaxhighlight lang=shell line>
# nano ~/.monitrc

set daemon 60 with start delay 10
set logfile /home/pacs/xyz00/users/zammad/monit/monit.log
set idfile /home/pacs/xyz00/users/zammad/monit/monit.id
set statefile /home/pacs/xyz00/users/zammad/monit/monit.state
set mailserver localhost
set mail-format { from: monit@your-domain.com }
#set httpd port 39008 address localhost
# allow zammadadmin:ein-monit-passwort
check process zammad_worker with pidfile /home/pacs/xyz00/users/zammad/monit/worker.pid
start program "/home/pacs/xyz00/users/zammad/monit/start-worker.sh"
stop program "/home/pacs/xyz00/users/zammad/monit/stop-worker.sh"
check process zammad_socket with pidfile /home/pacs/opa00/users/zammad/monit/socket.pid
start program "/home/pacs/xyz00/users/zammad/monit/start-websocket.sh"
stop program "/home/pacs/xyz00/users/zammad/monit/stop-websocket.sh"
</syntaxhighlight>

Noch schnell die rechte der 4 scripts anpassen:
chmod u+x ~/monit/*.sh

Monit kann dann mit
monit
gestartet werden.

Sobald monit einmal erfolgreich anlief sollte der monit Ordner so aussehen:

<syntaxhighlight lang=shell line>
# ls -lh

-rw-r--r-- 1 xyz00-zammad xyz00 32 Feb 23 11:59 monit.id
-rw-r--r-- 1 xyz00-zammad xyz00 2867 Feb 24 23:46 monit.log
-rw------- 1 xyz00-zammad xyz00 800 Feb 24 13:20 monit.state
-rw-r--r-- 1 xyz00-zammad xyz00 41048 Feb 25 00:49 socket.log
-rw-r--r-- 1 xyz00-zammad xyz00 5 Feb 24 23:45 socket.pid
-rwxr--r-- 1 xyz00-zammad xyz00 209 Feb 24 23:45 start-websocket.sh
-rwxr--r-- 1 xyz00-zammad xyz00 161 Feb 24 23:27 start-worker.sh
-rwxr--r-- 1 xyz00-zammad xyz00 34 Feb 24 23:30 stop-websocket.sh
-rwxr--r-- 1 xyz00-zammad xyz00 34 Feb 23 11:53 stop-worker.sh
-rw-r--r-- 1 xyz00-zammad xyz00 0 Feb 24 23:38 worker.log
-rw-r--r-- 1 xyz00-zammad xyz00 5 Feb 24 23:38 worker.pid
</syntaxhighlight>

== Optional: Mail-Piping ==

Um ein bisschen (viel) Last vom Background-Worker zu nehmen kann Mailpiping eingerichtet werden. Dafür sollte vermutlich zuerst der Webinstaller mit einer anderen IMAP/SMTP config durchgeklickt werden. Zusätzlich reduziert sich die Latenz von Maileingang bis Ticketeingang ein wenig.

=== Ausgangsserver auf sendmail festlegen ===

Der folgende Code schnippsel legt einen Mail-Kanal an, ohne einen dedizierten Eingang der regelmäßig abgerufen werden müsste. Quelle [https://admin-docs.zammad.org/en/latest/channels/email/advanced/sendmail.html]

<syntaxhighlight lang=ruby>
rails r "Channel.create(area: 'Email::Account', options: { inbound: { adapter: 'null', options: {} }, outbound: { adapter: 'sendmail' } }, active: true, preferences: { editable: false }, updated_by_id: 1, created_by_id: 1)"
</syntaxhighlight>

=== Maileingang per procmail ===

== Optional: Elasticsearch Anbindung ==

Weiteren User nach [[Elasticsearch]] anlegen. Dieser muss dann mit zammad verknüpft werden. Hier wird der Port 39200 angenommen.

<syntaxhighlight lang=shell>
cd ~/zammad
rails r "Setting.set('es_url', 'http://localhost:39200')"
rails r "Setting.set('es_user', 'elasticsearch')"
rails r "Setting.set('es_password', 'changeme')"
</syntaxhighlight>

Um Elasticsearch wieder zu deaktivieren einfach die URL durch einen leeren string ersetzen.

Es wird für Zammad 5.x ein ElasticSearch 7.x benötigt. siehe auch https://docs.zammad.org/en/latest/install/elasticsearch.html

Zum ersten Einrichten, oder auch zum Testen der Verbindung:

<syntaxhighlight lang=shell>
cd ~/zammad
rake searchindex:rebuild --trace
</syntaxhighlight>

Problem:
create indexes...rake aborted!
Can't find config setting 'es_multi_index'

Lösung:
<syntaxhighlight lang=shell>
psql -U xyz00_zammad
INSERT INTO settings \
(title, name, description, area, frontend, created_at, updated_at) \
VALUES ('ElasticSearch Multi Index', 'es_multi_index', \
'','SearchIndex::ElasticSearch', \
false, '2023-03-15 01:00:00', '2023-03-15 01:00:00');
cd ~/zammad
rails r "Setting.set('es_multi_index', false)"
rake searchindex:rebuild --trace
</syntaxhighlight>

== Zammad Upgrade ==

{{Baustelle}}

<syntaxhighlight lang=shell>
killall -u $USER
killall -u $USER 9

cp -a zammad zammad-old
cd zammad
rm -Rf app
rm -Rf public/assets
wget -O - https://ftp.zammad.com/zammad-5.3.1.tar.gz |tar -xvvz

bundle config set --local without 'test development mysql'
bundle install
</syntaxhighlight>

Geht nicht, Ruby 2.2.5 fehlt!

<syntaxhighlight lang=shell>
cd
rbenv install 2.5.5
</syntaxhighlight>

Geht nicht, Rbenv ist zu alt!

<syntaxhighlight lang=shell>
cd ~/.rbenv/plugins/ruby-build
git pull
cd
rbenv install 2.5.5
rbenv global 2.5.5
rbenv local 2.5.5

cd zammad
gem install bundle
gem install bundler
bundle config set --local without 'test development mysql'
bundle install

# Geht nicht, Bundler 1.17.x wird gebraucht.

gem install bundler==1.17.3

# Geht auch nicht.
# Dann hacken wir das mal versuchsweise ins Lock.

# vim Gemfile.lock

bundle config set --local without 'test development mysql'
bundle install

# Es fehlen Libs.
# HS bitte installieren...
# [...]
# Danke!

bundle config set --local without 'test development mysql'
bundle install
export RAILS_ENV=production
rake db:migrate
rake assets:clean
rake zammad:flush:cache
rake assets:precompile

/usr/bin/supervisord -c $HOME/supervisor/etc/supervisord.conf
</syntaxhighlight>

Nach Problemen mit Assets muss man den Dienst nochmal neustarten.

Nach dem Update testen, ob ElasticSearch noch funktioniert, eventuell muss auch ElasticSearch aktualisiert werden.

= weiterführende Links =

* [https://zammad.org/documentation Zammad Dokumentation]
* [https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/zammad Ansible Playbook für Hostsharing]

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:RubyOnRails]]
[[Kategorie:Helpdesk]]

Goaccess

2024-07-08T11:13:25Z

Opa00-hostsharing: small script optimization

Um den [[Traffic]] des Pakets beziehungweise die Einträge der [[Logging|Logdateien]] im grafischen Blick zu halten, falls das Vorgehen im gerade wenn unerwartet eine Mail mit erhöhtem Datenvolumen kommt (im terminal oder als webpage) bietet sich das tool goaccess an (https://goaccess.io/download). Es ist ein sehr schlankes tool was gerade mal 690kB im Download des tar.gz wiegt (Version 1.7)

[[Datei:Goacess.png|rahmenlos|Screenshot Goaccess]]

==Installation==

(Dieser Teil kann ausgelassen werden: Auf Managed Servern mit Debian Buster ist Goaccess Version 1.2 vorinstalliert, bei Debian Bookworm ist es Goaccess Version 1.7).

Die Installation ist erst einmal sehr einfach, daher kann es fast so installiert werden wie auf goaccess.io/download beschrieben:
eingeloggt als Paketadmin z.B. per ssh xyz00
Da wir als Paketadmin keine Programme für alle installieren kann ein lokales Directory für die Installation des Programms (und ähnlicher angelegt werden:
z.B. /home/pacs/xyz00/usr
~$mkdir usr
um dann automatisch dorthin auch ein /bin Ordner anzulegen (wird durch configure danach gemacht)
und auch den PATH anpassen, damit Programme hier in bin direkt ausgeführt werden.
~$ echo 'export PATH="$HOME/usr/bin:$PATH"' >>.bashrc
leider wird .bashrc nicht immer gelesen wenn wir mit ssh einloggen, wir müssen es in .bash_profile festlegen:
~$ echo '[[ -f ~/.bashrc ]] && . ~/.bashrc' >> ~/.bash_profile
nun sind wir bereit für die Installation:
~$ wget https://tar.goaccess.io/goaccess-1.7.tar.gz
~$ tar -xzvf goaccess-1.7.tar.gz
~$ cd goaccess-1.7/
Eine Systemweite Installation wird mangels Berechtigung nicht funktionieren. Damit configure direkt unseren Pfad anlegt, befehlen wir das Installationsdirectory $HOME als prefix
~/goaccess-1.7$ ./configure --enable-utf8 --enable-geoip=legacy --prefix=$HOME/usr
~/goaccess-1.7$ make
~/goaccess-1.7# make install
Nun liegt $HOME//usr/bin/goaccess in unserem PATH an erster Stelle
ein Aufruf von
~$ goaccess --version
sollte das zeigen
~$ goaccess --v
GoAccess - 1.7.
For more details visit: https://goaccess.io/
Copyright (C) 2009-2022 by Gerardo Orellana

Build configure arguments:
--enable-utf8
--enable-geoip=legacy

==Anwendung==
Dann, nach der Installation beginnt der hostsharingspezifische Teil, denn das file web.log, welches alle aktuellen logs der letzten zwei Tage beinhaltet beginnt nicht mit Datum und Uhrzeit, sondern mit den Domainnamen, was für goaccess zu Verwirrung führt.
=== Pipe mit zcat ===
Am leichtesten ist die Nutzung einer Pipe für die Prozessierung der gzip2 gezippten logfiles die alle nach dem Schema:
web-subdomain.example.com-YYYYMMDD-hhmm.log.gz im Ordner $HOME/var liegen.
Eine Auswertung des Weblogs von example.com z.B. vom 14.02.2023 liegt unter /home/pacs/xyz00/var/web-example.com-20230215-0139.log.gz vor
Die Auswertung muss also entzippt werden, das geht on-the-fly mit zcat
~$ zcat /home/pacs/xyz00/var/web-example.com-20230215-0139.log.gz
=== Wildcards ===
zcat kann sehr gut mit Wildcards umgehen, der Aufruf
~$ '''zcat ~/var/web*.log.gz''' | goaccess -o webstat.html --log-format=COMBINED -
zum Beispiel fasst alle logfiles aller Domains und aller Tage zusammen.
Es geht auch nur eine Domain: '''''"var/web-example.com*.log.gz"''''' oder nur den Januar 2023: '''''"var/web*202301*log.gz"''''' (es sollte beachtet werden, dass natürlich immer die Datei, die dann am Tag früh morgens (bei mir ist das zwischen 01:38h und 01:40h) erstellt wird natürlich für den vorherigen Tag ist. Das heißt in der 20230101 ist vor allem der 31.12. geloggt

=== Auswertung mit goaccess ===
~$ zcat ... | goaccess -o webstat.html --log-format=COMBINED -
legt eine Datei webstat.html im aktuellen Ordner ab, diese kann dann zum Beispiel heruntergeladen werden, oder in einer Domain erreichbar gemacht werden. '''Empfehlung:''' Datei per scp heruntergeladen, auf dem eigenen, geschützten Rechner angeschaut, und schnell vernichtet.
== Finetuning ==
=== Anonymisierte IPs ===
Um nur anonymisierte IPs anzeigen zu lassen kann das zusätzliche Flag --anonymize-ip verwendet werden

~$ zcat ... | goaccess ... --anonymize-ip -

In der Doku ist beschrieben wie die IP Adresse noch gröber anonymisiert werden kann.
=== Aktuellere Geo Location ===
Um die aktuellere Version der Geolocations zu verwenden muss bei

./configure ... --enable-geoip=mmdb ...

statt legacy verwendet werden. Dafür gibt es eine kostenlose Länder[https://db-ip.com/db/download/ip-to-country-lite] oder Städte[https://db-ip.com/db/download/ip-to-city-lite] lite-Version unter CC BY 4.0. Falls diese nicht genau genug sind, gibt es auch kommerzielle Alternativen vom selben Anbieter.

Die Datenbank sollte im mmdb format heruntergeladen werden. Der direkte Downloadlink kann von oben direkt kopiert werden. Der Download Befehl auf der Konsole könnte bspw so aussehen (Datum und Version beachten! ggf. Link selbst einfügen). Zum heutigen Stand hatte die lite-cities Datenbank eine Größe von rund 100 MB.

wget https://download.db-ip.com/free/dbip-city-lite-2023-02.mmdb.gz
gzip -d dbip-city-lite-2023-02.mmdb.gz

Beim ausführen von goaccess muss dann auch immer angegeben werden welche IP Datenbank verwendet werden soll. Dies geht mit folgendem zusätzlichen Flag (ggf. Pfad der db anpassen)
~$ zcat ... | goaccess ... --geoip-database=dbip-city-lite-2023-02.mmdb -

=== Automatisierung pro Domain des Paketes ===

Mit dem folgenden kleinen shell script kann in einer logs.example.com (muss ersetzt werden!) Domain die statischen html files zum ansehen hinterlegt werden. Diese sollten dort nicht ohne Login ausgeliefert werden und nicht ohne https. Grundsätzlich könnte goaccess die logs auch live aufbereiten, die Komprimierung könnte dort jedoch ggf in der neusten Version ein Hindernis darstellen.

#inhalt generate-logs.sh
logdom=logs.example.com
for dom in $(ls $HOME/var/ | cut -c5- | rev | cut -c22- | rev | sort | uniq) # list domain names
do
echo ${dom}
zcat $HOME/var/web-$dom-*.log.gz | goaccess -o $HOME/doms/$logdom/htdocs-ssl/$dom.html --log-format=COMBINED --anonymize-ip --geoip-database=dbip-city-lite-2023-02.mmdb --ignore-crawler --unknowns-as-crawlers -
done

Erklärung des scripts: Zuerst wird die logdomain auf der die Dateien abgelegt werden sollen festgelegt. Dann wird via find im Ordner /home/doms nach Dateien vom Typ Link gesucht, dessen Linkziel genauso beginnt wie das home des aktuellen users (der Paketuser). Es listet also alle domains, welche im aktuellen Paket Verwendung finden und iteriert über diese indem es die aktuelle Iteration in der Variablen dom speichert. Die nächste Zeile entfernt den Pfad vor dem Domainnamen, sodass die Variable nur noch den reinen Domainnamen beinhaltet. Der echo Befehl ist nur zur Übersicht beim manuellen ausführen und kann nach Wunsch mit # auskommentiert werden. Anschließend wird wie gewohnt (für jede Domain nacheinander) goaccess aufgerufen und für jede Domain eine eigene html Datei erzeugt. Eventuell muss der goaccess Befehl noch an die eigenen Wünsche angepasst werden.

Mit einem [[cron]] Eintrag könnte dieses Script regelmäßig aufgerufen werden. z.B.:

10 02 * * * sh ~/generate-logs.sh > /dev/null

== Warnung: Datenschutz ==
Man beachte, dass die Auswertungen Datenschutzrelevante Inhalte wie die IP Adresse und die aufgerufenen Pfade enthalten daher kann es nicht ausreichen nur die IPs zu anonymisieren. Bei einer Nextcloud Instanz beinhalten die Pfade z.B. häufig auch den Username und somit ggf. den Klarnamen. Entsprechend sollte diese Auswertung nicht öffentlich (ohne Passwortschutz) zugänglich gemacht werden. Siehe dazu [[.htaccess#Passwortschutz_f.C3.BCr_Dateien|Passwortschutz mit htaccess]].

== Weitere WebStatistik Tools bei HS ==

* [[AWStats_installieren|AWStat]]
* [[Goaccess]]
* [[Matomo Installieren|Matomo]]

[[Kategorie:Traffic]]
[[Kategorie:WebStatistik]]

Goaccess

2024-07-08T11:10:52Z

Opa00-hostsharing: Aktualisierung script, neue leserechte /home/doms/

Um den [[Traffic]] des Pakets beziehungweise die Einträge der [[Logging|Logdateien]] im grafischen Blick zu halten, falls das Vorgehen im gerade wenn unerwartet eine Mail mit erhöhtem Datenvolumen kommt (im terminal oder als webpage) bietet sich das tool goaccess an (https://goaccess.io/download). Es ist ein sehr schlankes tool was gerade mal 690kB im Download des tar.gz wiegt (Version 1.7)

[[Datei:Goacess.png|rahmenlos|Screenshot Goaccess]]

==Installation==

(Dieser Teil kann ausgelassen werden: Auf Managed Servern mit Debian Buster ist Goaccess Version 1.2 vorinstalliert, bei Debian Bookworm ist es Goaccess Version 1.7).

Die Installation ist erst einmal sehr einfach, daher kann es fast so installiert werden wie auf goaccess.io/download beschrieben:
eingeloggt als Paketadmin z.B. per ssh xyz00
Da wir als Paketadmin keine Programme für alle installieren kann ein lokales Directory für die Installation des Programms (und ähnlicher angelegt werden:
z.B. /home/pacs/xyz00/usr
~$mkdir usr
um dann automatisch dorthin auch ein /bin Ordner anzulegen (wird durch configure danach gemacht)
und auch den PATH anpassen, damit Programme hier in bin direkt ausgeführt werden.
~$ echo 'export PATH="$HOME/usr/bin:$PATH"' >>.bashrc
leider wird .bashrc nicht immer gelesen wenn wir mit ssh einloggen, wir müssen es in .bash_profile festlegen:
~$ echo '[[ -f ~/.bashrc ]] && . ~/.bashrc' >> ~/.bash_profile
nun sind wir bereit für die Installation:
~$ wget https://tar.goaccess.io/goaccess-1.7.tar.gz
~$ tar -xzvf goaccess-1.7.tar.gz
~$ cd goaccess-1.7/
Eine Systemweite Installation wird mangels Berechtigung nicht funktionieren. Damit configure direkt unseren Pfad anlegt, befehlen wir das Installationsdirectory $HOME als prefix
~/goaccess-1.7$ ./configure --enable-utf8 --enable-geoip=legacy --prefix=$HOME/usr
~/goaccess-1.7$ make
~/goaccess-1.7# make install
Nun liegt $HOME//usr/bin/goaccess in unserem PATH an erster Stelle
ein Aufruf von
~$ goaccess --version
sollte das zeigen
~$ goaccess --v
GoAccess - 1.7.
For more details visit: https://goaccess.io/
Copyright (C) 2009-2022 by Gerardo Orellana

Build configure arguments:
--enable-utf8
--enable-geoip=legacy

==Anwendung==
Dann, nach der Installation beginnt der hostsharingspezifische Teil, denn das file web.log, welches alle aktuellen logs der letzten zwei Tage beinhaltet beginnt nicht mit Datum und Uhrzeit, sondern mit den Domainnamen, was für goaccess zu Verwirrung führt.
=== Pipe mit zcat ===
Am leichtesten ist die Nutzung einer Pipe für die Prozessierung der gzip2 gezippten logfiles die alle nach dem Schema:
web-subdomain.example.com-YYYYMMDD-hhmm.log.gz im Ordner $HOME/var liegen.
Eine Auswertung des Weblogs von example.com z.B. vom 14.02.2023 liegt unter /home/pacs/xyz00/var/web-example.com-20230215-0139.log.gz vor
Die Auswertung muss also entzippt werden, das geht on-the-fly mit zcat
~$ zcat /home/pacs/xyz00/var/web-example.com-20230215-0139.log.gz
=== Wildcards ===
zcat kann sehr gut mit Wildcards umgehen, der Aufruf
~$ '''zcat ~/var/web*.log.gz''' | goaccess -o webstat.html --log-format=COMBINED -
zum Beispiel fasst alle logfiles aller Domains und aller Tage zusammen.
Es geht auch nur eine Domain: '''''"var/web-example.com*.log.gz"''''' oder nur den Januar 2023: '''''"var/web*202301*log.gz"''''' (es sollte beachtet werden, dass natürlich immer die Datei, die dann am Tag früh morgens (bei mir ist das zwischen 01:38h und 01:40h) erstellt wird natürlich für den vorherigen Tag ist. Das heißt in der 20230101 ist vor allem der 31.12. geloggt

=== Auswertung mit goaccess ===
~$ zcat ... | goaccess -o webstat.html --log-format=COMBINED -
legt eine Datei webstat.html im aktuellen Ordner ab, diese kann dann zum Beispiel heruntergeladen werden, oder in einer Domain erreichbar gemacht werden. '''Empfehlung:''' Datei per scp heruntergeladen, auf dem eigenen, geschützten Rechner angeschaut, und schnell vernichtet.
== Finetuning ==
=== Anonymisierte IPs ===
Um nur anonymisierte IPs anzeigen zu lassen kann das zusätzliche Flag --anonymize-ip verwendet werden

~$ zcat ... | goaccess ... --anonymize-ip -

In der Doku ist beschrieben wie die IP Adresse noch gröber anonymisiert werden kann.
=== Aktuellere Geo Location ===
Um die aktuellere Version der Geolocations zu verwenden muss bei

./configure ... --enable-geoip=mmdb ...

statt legacy verwendet werden. Dafür gibt es eine kostenlose Länder[https://db-ip.com/db/download/ip-to-country-lite] oder Städte[https://db-ip.com/db/download/ip-to-city-lite] lite-Version unter CC BY 4.0. Falls diese nicht genau genug sind, gibt es auch kommerzielle Alternativen vom selben Anbieter.

Die Datenbank sollte im mmdb format heruntergeladen werden. Der direkte Downloadlink kann von oben direkt kopiert werden. Der Download Befehl auf der Konsole könnte bspw so aussehen (Datum und Version beachten! ggf. Link selbst einfügen). Zum heutigen Stand hatte die lite-cities Datenbank eine Größe von rund 100 MB.

wget https://download.db-ip.com/free/dbip-city-lite-2023-02.mmdb.gz
gzip -d dbip-city-lite-2023-02.mmdb.gz

Beim ausführen von goaccess muss dann auch immer angegeben werden welche IP Datenbank verwendet werden soll. Dies geht mit folgendem zusätzlichen Flag (ggf. Pfad der db anpassen)
~$ zcat ... | goaccess ... --geoip-database=dbip-city-lite-2023-02.mmdb -

=== Automatisierung pro Domain des Paketes ===

Mit dem folgenden kleinen shell script kann in einer logs.example.com (muss ersetzt werden!) Domain die statischen html files zum ansehen hinterlegt werden. Diese sollten dort nicht ohne Login ausgeliefert werden und nicht ohne https. Grundsätzlich könnte goaccess die logs auch live aufbereiten, die Komprimierung könnte dort jedoch ggf in der neusten Version ein Hindernis darstellen.

#inhalt generate-logs.sh
logdom=logs.example.com
for dom in $(ls $HOME/var/ | cut -c5- | rev | cut -c22- | rev | sort | uniq) # list domain names
do
dom=${dom##*/}
echo ${dom}
zcat $HOME/var/web-$dom-*.log.gz | goaccess -o $HOME/doms/$logdom/htdocs-ssl/$dom.html --log-format=COMBINED --anonymize-ip --geoip-database=dbip-city-lite-2023-02.mmdb --ignore-crawler --unknowns-as-crawlers -
done

Erklärung des scripts: Zuerst wird die logdomain auf der die Dateien abgelegt werden sollen festgelegt. Dann wird via find im Ordner /home/doms nach Dateien vom Typ Link gesucht, dessen Linkziel genauso beginnt wie das home des aktuellen users (der Paketuser). Es listet also alle domains, welche im aktuellen Paket Verwendung finden und iteriert über diese indem es die aktuelle Iteration in der Variablen dom speichert. Die nächste Zeile entfernt den Pfad vor dem Domainnamen, sodass die Variable nur noch den reinen Domainnamen beinhaltet. Der echo Befehl ist nur zur Übersicht beim manuellen ausführen und kann nach Wunsch mit # auskommentiert werden. Anschließend wird wie gewohnt (für jede Domain nacheinander) goaccess aufgerufen und für jede Domain eine eigene html Datei erzeugt. Eventuell muss der goaccess Befehl noch an die eigenen Wünsche angepasst werden.

Mit einem [[cron]] Eintrag könnte dieses Script regelmäßig aufgerufen werden. z.B.:

10 02 * * * sh ~/generate-logs.sh > /dev/null

== Warnung: Datenschutz ==
Man beachte, dass die Auswertungen Datenschutzrelevante Inhalte wie die IP Adresse und die aufgerufenen Pfade enthalten daher kann es nicht ausreichen nur die IPs zu anonymisieren. Bei einer Nextcloud Instanz beinhalten die Pfade z.B. häufig auch den Username und somit ggf. den Klarnamen. Entsprechend sollte diese Auswertung nicht öffentlich (ohne Passwortschutz) zugänglich gemacht werden. Siehe dazu [[.htaccess#Passwortschutz_f.C3.BCr_Dateien|Passwortschutz mit htaccess]].

== Weitere WebStatistik Tools bei HS ==

* [[AWStats_installieren|AWStat]]
* [[Goaccess]]
* [[Matomo Installieren|Matomo]]

[[Kategorie:Traffic]]
[[Kategorie:WebStatistik]]

Vaultwarden

2024-06-25T15:24:04Z

Opa00-hostsharing: WIP vaultwarden

Vaultwarden, früher bekannt als Bitwarden_RS, ist eine leichtgewichtige und performante Open-Source-Alternative zu Bitwarden. Es handelt sich um eine selbst gehostete Passwortverwaltungslösung, die vollständig mit dem offiziellen Bitwarden-Ökosystem kompatibel ist. Vaultwarden ermöglicht es, sensible Zugangsdaten, sichere Notizen und andere geheime Informationen zentral und sicher zu verwalten.

Mit minimalen Systemanforderungen kann Vaultwarden problemlos auf ressourcenschwachen Systemen oder in Containern betrieben werden. Es unterstützt Funktionen wie Zwei-Faktor-Authentifizierung (2FA), End-to-End-Verschlüsselung und die Integration in bestehende Verzeichnisdienste. Vaultwarden bietet zudem eine Webschnittstelle und verschiedene Clients für eine nahtlose Benutzererfahrung.

= Installation =

== Cargo herunterladen ==

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
source $HOME/.cargo/env

== Vaultvarden herunterladen und builden ==

git clone https://github.com/dani-garcia/vaultwarden.git
cargo build --features postgresql --release

== Auf eine Domain aufschalten ==

run.sh
#!/bin/bash
screen -dmS bitwarden ~/vaultwarden/target/release/vaultwarden

=== .env File ===

Passe den Port nach belieben an, und stelle sicher das die SQL Daten (user, passwort und dbname) und der admin token stimmen, die vollständigen Informationen und alle setzbare Optionen (und deren defaults) findet sich unter https://raw.githubusercontent.com/dani-garcia/vaultwarden/main/.env.template

## Be aware that most of these settings will be overridden if they were changed
## in the admin interface. Those overrides are stored within DATA_FOLDER/config.json .
##
## By default, Vaultwarden expects for this file to be named ".env" and located
## in the current working directory. If this is not the case, the environment
## variable ENV_FILE can be set to the location of this file prior to starting
## Vaultwarden.
DOMAIN=https://bitwarden.example.com
SIGNUPS_ALLOWED=false
ROCKET_ADDRESS=127.0.0.1
ROCKET_PORT=8222
DATABASE_URL='postgresql://xyz00_bitwarden:thesqlpassword@localhost/xyz00_bitwarden'
SMTP_HOST=127.0.0.1
SMTP_PORT=25
SMTP_SSL=false
SMTP_FROM=bitwarden@example.com
SMTP_FROM_NAME="My Personal Bitwarden"
ADMIN_TOKEN=<someverLonganduniquetoken>
ORG_CREATION_USERS=user@example.com
REQUIRE_DEVICE_EMAIL=true

=== .htaccess ===
Falls du den Port angepasst hast muss er auch hier angepasst werden.

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{HTTP:UPGRADE} ^WebSocket$ [NC,OR]
RewriteCond %{HTTP:CONNECTION} ^Upgrade$ [NC]
RewriteRule .* ws://127.0.0.1:8222%{REQUEST_URI} [proxy]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
RewriteRule .* http://127.0.0.1:8222%{REQUEST_URI} [proxy,last]

=== Weboberfläche bereitstellen ===

Versionsnummer anpassen, herunterladen und entpacken https://github.com/dani-garcia/bw_web_builds/releases/

wget https://github.com/dani-garcia/bw_web_builds/releases/download/v2022.6.2/bw_web_v2022.6.2.tar.gz
tar xvf bw_web_v2022.6.2.tar.gz
rm bw_web_v2022.6.2.tar.gz

Zammad

2024-05-14T07:55:51Z

Opa00-hostsharing: /* Zammad ausliefern */

== Anforderungen ==
Zammad ist ein relativ umfangreiches, mächtiges und modernes OSS Helpdesk Tool. Für die Installation wird benötigt:

* eine (Sub)Domain
* 2 bis 4 GB RAM (Schätzung, eure Erfahrung kann abweichen, je nach Nutzung)
* ruby
* nodejs
* mehrere Daemons für Hintergrunddienste (worker, websocket)
* evtl. noch ElasticSearch für Volltextsuche

== Installation ==

Die Installation orientiert sich an dieser Anleitung und wurde für zammad 6.3 verfasst.
Einige HS spezifische Abweichungen gibt es jedoch.

* https://docs.zammad.org/en/latest/install/source.html

=== User anlegen ===
Für diese Anleitung wird angenommen das der User unter dem zammad laufen soll xyz00-zammad im Packet xyz00 ist.

=== Installation ruby / ruby env ===
Prüfe die Version von ruby die zammad benötigt [https://docs.zammad.org/en/latest/prerequisites/software.html#ruby-programming-language hier].

Für diese Anleitung nehmen wir Version 3.2.3 an für zammad 6.3.

Die Installationsanleitung für rubyenv und ruby findet sich unter [[RubyRBEnv]].

Verifiziere das die Installation geklappt hat mit
ruby -v
dies sollte der herausgesuchten Versionsnummer entsprechen

=== Installation nodejs ===
Prüfe die Version von nodejs die zammad benötigt [https://docs.zammad.org/en/latest/prerequisites/software.html#node-js hier].

Für diese Anleitung nehmen wir Version 20 an für zammad 6.3.

Verifiziere das die Installation geklappt hat mit
node -v
dies sollte der herausgesuchten Versionsnummer entsprechen

=== Installation Redis ===

Siehe [[Redis]]

=== Umgebungsvariablen ===

Meine `.profile`, `.bashrc`, `.bash_profile` sahen dann wie folgt aus (möglicherweise gibt es hier optimierungspotential)

Die Datei `.bash_profile`:
. ~/.profile
. ~/.bashrc
Die Datei `.profile` (vgl instalation ruby und nodejs):
#ruby
export PATH="$HOME/.rbenv/bin:$PATH"
eval "$(rbenv init -)"
#nodejs
export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh" # This loads nvm
[ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion" # This loads nvm bash_completion
und die Datei `.bashrc`. Quellen vgl. [https://github.com/zammad/zammad/tree/develop/script/systemd/zammad.env] und [https://docs.zammad.org/en/latest/appendix/configure-env-vars.html#performance-tuning]

export REDIS_URL=redis://:<your-password-goes-here>@127.0.0.1:<port>

export RAILS_ENV=production

Dann entweder alles neu einlesen oder einmal aus und wieder einloggen. Wenn alles geklappt hat, sollten die folgenden Befehle alle sinnvolle Ausgaben liefern
echo $RAILS_ENV # Ausgabe: production
ruby -v # Ausgabe vgl. oben
nodejs -v # Ausgabe vgl. oben

=== Installation von Zammad ===
Zuerst laden wir zammad herunter, entpacken es, und installieren die dependencies (nur production)

mkdir zammad
cd zammad
wget -O - https://ftp.zammad.com/zammad-latest.tar.gz |tar -xvvz
bundle config set --local without 'test development mysql'
bundle install

Dann tragen wir die zugangsdaten der postgres Datenbank ein (auf HS Admin selbst erstellen) hier: beides `xyz00_zammad`
Mit folgendem Inhalt (Einrückung beachten!):
nano config/database.yml

# config/database.yml
production:
adapter: postgresql
host: localhost
database: xyz00_zammad
pool: 50
timeout: 5000
encoding: utf8
username: xyz00_zammad
password: changeme

Wenn alles stimmt sollten sich die folgenden Befehle ohne Fehler ausführen lassen und die Datenbanktabellen sowie die statischen Dateien zum ausliefern anlegen

rake db:migrate
rake assets:precompile

=== Zammad ausliefern ===
Um via Browser auf zammad zugreifen zu können kann es via [[Phusion Passenger]] ausgeliefert werden. Dazu muss im HS Admin eine Domain aufgeschaltet werden. Dann wird:
* die .htaccess wie folgend gesetzt werden
* der zammad ordner nach app-ssl gelinkt werden
* und der statische content in htdocs-ssl
* Optional kann das Domain Template noch um die subdomains bereinigt werden (2. Befehl)

cd ~/doms/zammad.example.org/
rm -r subs*
rm -r htdocs-ssl
rm -r app-ssl
ln -s ~/zammad app-ssl
ln -s ~/zammad/public htdocs-ssl
nano .htaccess

In HS-Admin muss unter der Domain dann folgende Eigenschaft bei Passenger gesetzt werden:

PassengerRuby /home/pacs/xyz00/users/zammad/.rbenv/shims/ruby

# Inhalt .htaccess
DirectoryIndex disabled
RewriteEngine On
RewriteBase /

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{HTTP:Connection} Upgrade [NC]
RewriteCond %{HTTP:Upgrade} websocket [NC]
RewriteRule .* ws://127.0.0.1:6042/%{REQUEST_URI} [P,L]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RequestHeader set X-Forwarded-Proto "https"
RewriteRule .* http://127.0.0.1:6041/%{REQUEST_URI} [proxy,last]

Wenn alles geklappt hat sollte auf der Domain das restliche Web-basierte Setup zu sehen sein. Dort muss dann auch der andere HS Postfach User eingetragen werden. Theoretisch könnte man das auf dem gleichen Account abwickeln, ich persönlich würde es allerdings trennen. Piping wie bei manch andren Mailbasierten Anwendungen scheint nicht so einfach möglich zu sein (needs more investigation)

=== Hintergrunddienste ===

Damit der Websocket-Server und der Hintergrund Worker ordentlich laufen müssen folgende Befehle ausgeführt werden. Die IP Adresse und der Port beim Socket werden aus den Enviroment Variablen von oben bezogen, können allerdings auch manuell gesetzt werden.
cd zammad
bundle exec script/background-worker.rb start
bundle exec script/websocket-server.rb -b ${ZAMMAD_BIND_IP} -p ${ZAMMAD_WEBSOCKET_PORT} start

== Empfohlen: Monit ==
Ich habe alles monit spezifische in den ordner monit gepackt
cd
mkdir monit
cd monit
Zum starten habe ich ein kleines start und stop script (für monit) erstellt (lange zeile ggf. beachten)

nano start-worker.sh

#!/bin/bash
. ~/.bash_profile
cd ~/zammad
exec ${BUNDLE_BINARY} exec script/background-worker.rb start > ~/monit/worker.log 2>&1 &
echo $! > ~/monit/worker.pid

nano start-websocket.sh

#!/bin/bash
. ~/.bash_profile
cd ~/zammad
# warnung, der socket produziert relativ viel log output im normalen Betrieb ggf. anpassen
exec ${BUNDLE_BINARY} exec script/websocket-server.rb -b ${ZAMMAD_BIND_IP} -p ${ZAMMAD_WEBSOCKET_PORT} start > ~/monit/socket.log 2>&1 &
echo $! > ~/monit/socket.pid

nano stop-worker.sh

kill $( cat ~/monit/worker.pid )

nano stop-websocket.sh

kill $( cat ~/monit/socket.pid )

Das dann alles noch in der `~/.monitrc` zusammenführen (achtung einige xyz00, zammad (user) und Mail Platzhalter):

nano ~/.monitrc

set daemon 60 with start delay 10
set logfile /home/pacs/xyz00/users/zammad/monit/monit.log
set idfile /home/pacs/xyz00/users/zammad/monit/monit.id
set statefile /home/pacs/xyz00/users/zammad/monit/monit.state
set mailserver localhost
set mail-format { from: monit@your-domain.com }
#set httpd port 39008 address localhost
# allow zammadadmin:ein-monit-passwort
check process zammad_worker with pidfile /home/pacs/xyz00/users/zammad/monit/worker.pid
start program "/home/pacs/xyz00/users/zammad/monit/start-worker.sh"
stop program "/home/pacs/xyz00/users/zammad/monit/stop-worker.sh"
check process zammad_socket with pidfile /home/pacs/opa00/users/zammad/monit/socket.pid
start program "/home/pacs/xyz00/users/zammad/monit/start-websocket.sh"
stop program "/home/pacs/xyz00/users/zammad/monit/stop-websocket.sh"

Noch schnell die rechte der 4 scripts anpassen:
chmod u+x ~/monit/*.sh

Monit kann dann mit
monit
gestartet werden.

Sobald monit einmal erfolgreich anlief sollte der monit Ordner so aussehen:
ls -lh

-rw-r--r-- 1 xyz00-zammad xyz00 32 Feb 23 11:59 monit.id
-rw-r--r-- 1 xyz00-zammad xyz00 2867 Feb 24 23:46 monit.log
-rw------- 1 xyz00-zammad xyz00 800 Feb 24 13:20 monit.state
-rw-r--r-- 1 xyz00-zammad xyz00 41048 Feb 25 00:49 socket.log
-rw-r--r-- 1 xyz00-zammad xyz00 5 Feb 24 23:45 socket.pid
-rwxr--r-- 1 xyz00-zammad xyz00 209 Feb 24 23:45 start-websocket.sh
-rwxr--r-- 1 xyz00-zammad xyz00 161 Feb 24 23:27 start-worker.sh
-rwxr--r-- 1 xyz00-zammad xyz00 34 Feb 24 23:30 stop-websocket.sh
-rwxr--r-- 1 xyz00-zammad xyz00 34 Feb 23 11:53 stop-worker.sh
-rw-r--r-- 1 xyz00-zammad xyz00 0 Feb 24 23:38 worker.log
-rw-r--r-- 1 xyz00-zammad xyz00 5 Feb 24 23:38 worker.pid

== Optional: Mail-Piping ==

Um ein bisschen (viel) Last vom Background-Worker zu nehmen kann Mailpiping eingerichtet werden. Dafür sollte vermutlich zuerst der Webinstaller mit einer anderen IMAP/SMTP config durchgeklickt werden. Zusätzlich reduziert sich die Latenz von Maileingang bis Ticketeingang ein wenig.

=== Ausgangsserver auf sendmail festlegen ===

Der folgende Code schnippsel legt einen Mail-Kanal an, ohne einen dedizierten Eingang der regelmäßig abgerufen werden müsste. Quelle [https://admin-docs.zammad.org/en/latest/channels/email/advanced/sendmail.html]

rails r "Channel.create(area: 'Email::Account', options: { inbound: { adapter: 'null', options: {} }, outbound: { adapter: 'sendmail' } }, active: true, preferences: { editable: false }, updated_by_id: 1, created_by_id: 1)"

=== Maileingang per procmail ===

== Optional: Elasticsearch Anbindung ==

Weiteren User nach [[Elasticsearch]] anlegen. Dieser muss dann mit zammad verknüpft werden. Hier wird der Port 39200 angenommen.

cd ~/zammad
rails r "Setting.set('es_url', 'http://localhost:39200')"
rails r "Setting.set('es_user', 'elasticsearch')"
rails r "Setting.set('es_password', 'changeme')"

Um Elasticsearch wieder zu deaktivieren einfach die URL durch einen leeren string ersetzen.

Es wird für Zammad 5.x ein ElasticSearch 7.x benötigt. siehe auch https://docs.zammad.org/en/latest/install/elasticsearch.html

Zum ersten Einrichten, oder auch zum Testen der Verbindung:

cd ~/zammad
rake searchindex:rebuild --trace

Problem:
create indexes...rake aborted!
Can't find config setting 'es_multi_index'

Lösung:
<pre>
psql -U xyz00_zammad
INSERT INTO settings \
(title, name, description, area, frontend, created_at, updated_at) \
VALUES ('ElasticSearch Multi Index', 'es_multi_index', \
'','SearchIndex::ElasticSearch', \
false, '2023-03-15 01:00:00', '2023-03-15 01:00:00');
cd ~/zammad
rails r "Setting.set('es_multi_index', false)"
rake searchindex:rebuild --trace
</pre>

== Zammad Upgrade ==

{{Baustelle}}

<pre>
killall -u $USER
killall -u $USER 9

cp -a zammad zammad-old
cd zammad
rm -Rf app
rm -Rf public/assets
wget -O - https://ftp.zammad.com/zammad-5.3.1.tar.gz |tar -xvvz

bundle config set --local without 'test development mysql'
bundle install

Geht nicht, Ruby 2.2.5 fehlt!

cd
rbenv install 2.5.5

Geht nicht, Rbenv ist zu alt!

cd ~/.rbenv/plugins/ruby-build
git pull
cd
rbenv install 2.5.5
rbenv global 2.5.5
rbenv local 2.5.5

cd zammad
gem install bundle
gem install bundler
bundle config set --local without 'test development mysql'
bundle install

Geht nicht, Bundler 1.17.x wird gebraucht.

gem install bundler==1.17.3

Geht auch nicht.
Dann hacken wir das mal versuchsweise ins Lock.

vim Gemfile.lock

bundle config set --local without 'test development mysql'
bundle install

Es fehlen Libs.
HS bitte installieren...
[...]
Danke!

bundle config set --local without 'test development mysql'
bundle install
export RAILS_ENV=production
rake db:migrate
rake assets:clean
rake zammad:flush:cache
rake assets:precompile

/usr/bin/supervisord -c $HOME/supervisor/etc/supervisord.conf
</pre>

Nach Problemen mit Assets muss man den Dienst nochmal neustarten.

Nach dem Update testen, ob ElasticSearch noch funktioniert, eventuell muss auch ElasticSearch aktualisiert werden.

= weiterführende Links =

* [https://zammad.org/documentation Zammad Dokumentation]
* [https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/zammad Ansible Playbook für Hostsharing]

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:RubyOnRails]]
[[Kategorie:Helpdesk]]

Redis

2024-05-14T07:52:19Z

Opa00-hostsharing: changed for new debian

== Redis installieren ==

'''Redis''' ist ein einfacher Datenspeicher für Schlüssel-Wert-Paare. Datensätze werden jeweils unter einem Schlüssel abgelegt. Die Daten werden jeweils im Hauptspeicher gehalten und nur zu konfigurierbaren Zeitpunkten auf die Festplatte gesichert.

Redis-Datenbanken werden häufig zur Speicherung von Warteschlangen benutzt. In Redis werden Aufträge gespeichert, die asynchron von Hintergrundprogrammen abgearbeitet werden.

=== Konfiguration ===

Redis ist auf den Hostsharing-Servern vorinstalliert. Für die Nutzung muss lediglich eine Konfigurationsdatei angelegt werden und ein Hitergrundprogramm gestartet werden.

Im folgenden wird für den User ''xyz00-service'' ein Redis-Dienst eingerichtet.
Der User ''xyz00-service'' ist in HSAdmin mit ''/bin/bash'' als Shell eingerichtet.

Nach dem Login als ''xyz00-service'' lege ich Verzeichnisse ''~/redis/etc'' und ''~/redis/var'' an:

xyz00-service@h00:~$ mkdir redis
xyz00-service@h00:~$ mkdir redis/etc
xyz00-service@h00:~$ mkdir redis/var

Im etc-Verzeichnis wird die Konfigurationsdatei ''redis.conf'' für den Redis-Dienst abgelegt.

Eine Beispiel-Konfiguration ist:

requirepass <generiertes-passwort>
bind 127.0.0.1
port 33033
tcp-backlog 128
timeout 300
loglevel notice
logfile /home/pacs/xyz00/users/service/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/service/redis/var/

Der Redis-Dienst ist über die Server-lokale Netzwerk-Adresse 127.0.0.1 erreichbar und mit einem Passwort geschützt. Der Port ''33033'' für die Netzwerk-Schnittstelle muss ggf. angepasst werden.

Der Dienst wird gestartet mit:

xyz00-service@h00:~/redis$ /usr/bin/redis-server etc/redis.conf

Mit Ctrl-C kann der Dienst wieder gestoppt werden.

Alternativ kann der zugriff auf Redis über einen Unixsocket erfolgen. Dann entfällt die Zeile 'bind 127.0.0.1' in der Konfiguration, der port wird auf 0 gesetzt. Stattdessen wir ein Unixsocket konfiguriert:

unixsocket /home/pacs/xyz00/users/service/redis/var/redis-server.sock
unixsocketperm 700
port 0

(der Unixsocket benötigt in der Konfiguration den vollständigen absoluten Pfad zum Socket im Dateisystem!)

=== Einrichtung als Server-Dienst ===

'''Redis''' soll über den Systemdienst '''SystemD''' automatisch im Hintergrund gestartet werden.

Dazu wird im Verzeichnis ''~/.config/systemd/user'' eine Datei ''redis.service'' mit dem folgenden Inhalt angelegt:

[Unit]
Description=Redis Service

[Service]
WorkingDirectory=%h/redis
Environment="PATH=/usr/local/bin:/usr/bin:/bin"
ExecStart=/usr/bin/redis-server %h/redis/etc/redis.conf
Restart=always
PrivateTmp=true
NoNewPrivileges=true

[Install]
WantedBy=default.target

Die Datei wird mit den folgenden Shell-Kommandos geladen und aktiviert:

systemctl --user daemon-reload
systemctl --user enable redis.service
systemctl --user start redis.service

Mit den Kommandos

systemctl --user status
systemctl --user status redis.service

kann der Status des Dienstes ermittelt werden.

=== Links ===

* [https://redis.io/ Internetseite des Redis Projekts]

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

Zammad

2024-05-14T07:38:39Z

Opa00-hostsharing: /* Installation von Zammad */

== Anforderungen ==
Zammad ist ein relativ umfangreiches, mächtiges und modernes OSS Helpdesk Tool. Für die Installation wird benötigt:

* eine (Sub)Domain
* 2 bis 4 GB RAM (Schätzung, eure Erfahrung kann abweichen, je nach Nutzung)
* ruby
* nodejs
* mehrere Daemons für Hintergrunddienste (worker, websocket)
* evtl. noch ElasticSearch für Volltextsuche

== Installation ==

Die Installation orientiert sich an dieser Anleitung und wurde für zammad 6.3 verfasst.
Einige HS spezifische Abweichungen gibt es jedoch.

* https://docs.zammad.org/en/latest/install/source.html

=== User anlegen ===
Für diese Anleitung wird angenommen das der User unter dem zammad laufen soll xyz00-zammad im Packet xyz00 ist.

=== Installation ruby / ruby env ===
Prüfe die Version von ruby die zammad benötigt [https://docs.zammad.org/en/latest/prerequisites/software.html#ruby-programming-language hier].

Für diese Anleitung nehmen wir Version 3.2.3 an für zammad 6.3.

Die Installationsanleitung für rubyenv und ruby findet sich unter [[RubyRBEnv]].

Verifiziere das die Installation geklappt hat mit
ruby -v
dies sollte der herausgesuchten Versionsnummer entsprechen

=== Installation nodejs ===
Prüfe die Version von nodejs die zammad benötigt [https://docs.zammad.org/en/latest/prerequisites/software.html#node-js hier].

Für diese Anleitung nehmen wir Version 20 an für zammad 6.3.

Verifiziere das die Installation geklappt hat mit
node -v
dies sollte der herausgesuchten Versionsnummer entsprechen

=== Installation Redis ===

Siehe [[Redis]]

=== Umgebungsvariablen ===

Meine `.profile`, `.bashrc`, `.bash_profile` sahen dann wie folgt aus (möglicherweise gibt es hier optimierungspotential)

Die Datei `.bash_profile`:
. ~/.profile
. ~/.bashrc
Die Datei `.profile` (vgl instalation ruby und nodejs):
#ruby
export PATH="$HOME/.rbenv/bin:$PATH"
eval "$(rbenv init -)"
#nodejs
export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh" # This loads nvm
[ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion" # This loads nvm bash_completion
und die Datei `.bashrc`. Quellen vgl. [https://github.com/zammad/zammad/tree/develop/script/systemd/zammad.env] und [https://docs.zammad.org/en/latest/appendix/configure-env-vars.html#performance-tuning]

export REDIS_URL=redis://:<your-password-goes-here>@127.0.0.1:<port>

export RAILS_ENV=production

Dann entweder alles neu einlesen oder einmal aus und wieder einloggen. Wenn alles geklappt hat, sollten die folgenden Befehle alle sinnvolle Ausgaben liefern
echo $RAILS_ENV # Ausgabe: production
ruby -v # Ausgabe vgl. oben
nodejs -v # Ausgabe vgl. oben

=== Installation von Zammad ===
Zuerst laden wir zammad herunter, entpacken es, und installieren die dependencies (nur production)

mkdir zammad
cd zammad
wget -O - https://ftp.zammad.com/zammad-latest.tar.gz |tar -xvvz
bundle config set --local without 'test development mysql'
bundle install

Dann tragen wir die zugangsdaten der postgres Datenbank ein (auf HS Admin selbst erstellen) hier: beides `xyz00_zammad`
Mit folgendem Inhalt (Einrückung beachten!):
nano config/database.yml

# config/database.yml
production:
adapter: postgresql
host: localhost
database: xyz00_zammad
pool: 50
timeout: 5000
encoding: utf8
username: xyz00_zammad
password: changeme

Wenn alles stimmt sollten sich die folgenden Befehle ohne Fehler ausführen lassen und die Datenbanktabellen sowie die statischen Dateien zum ausliefern anlegen

rake db:migrate
rake assets:precompile

=== Zammad ausliefern ===
Um via Browser auf zammad zugreifen zu können kann es via [[Phusion Passenger]] ausgeliefert werden. Dazu muss im HS Admin eine Domain aufgeschaltet werden. Dann wird:
* die .htaccess wie folgend gesetzt werden
* der zammad ordner nach app-ssl gelinkt werden
* und der statische content in htdocs-ssl
* Optional kann das Domain Template noch um die subdomains bereinigt werden (2. Befehl)

cd ~/doms/zammad.example.org/
rm -r subs*
rm -r htdocs-ssl
rm -r app-ssl
ln -s ~/zammad app-ssl
ln -s ~/zammad/public htdocs-ssl
nano .htaccess

# Inhalt .htaccess
#PassengerFriendlyErrorPages on # falls nötig zum debuggen einkommentieren
RackEnv production
RailsEnv production
PassengerRuby /home/pacs/xyz00/users/zammad/.rbenv/shims/ruby
# local websocket ssl forwarding
RewriteCond %{HTTP:Connection} Upgrade [NC]
RewriteCond %{HTTP:Upgrade} websocket [NC]
RewriteRule /(.*) ws://127.0.0.1:6042/$1 [P,L]

Wenn alles geklappt hat sollte auf der Domain das restliche Web-basierte Setup zu sehen sein. Dort muss dann auch der andere HS Postfach User eingetragen werden. Theoretisch könnte man das auf dem gleichen Account abwickeln, ich persönlich würde es allerdings trennen. Piping wie bei manch andren Mailbasierten Anwendungen scheint nicht so einfach möglich zu sein (needs more investigation)

=== Hintergrunddienste ===

Damit der Websocket-Server und der Hintergrund Worker ordentlich laufen müssen folgende Befehle ausgeführt werden. Die IP Adresse und der Port beim Socket werden aus den Enviroment Variablen von oben bezogen, können allerdings auch manuell gesetzt werden.
cd zammad
bundle exec script/background-worker.rb start
bundle exec script/websocket-server.rb -b ${ZAMMAD_BIND_IP} -p ${ZAMMAD_WEBSOCKET_PORT} start

== Empfohlen: Monit ==
Ich habe alles monit spezifische in den ordner monit gepackt
cd
mkdir monit
cd monit
Zum starten habe ich ein kleines start und stop script (für monit) erstellt (lange zeile ggf. beachten)

nano start-worker.sh

#!/bin/bash
. ~/.bash_profile
cd ~/zammad
exec ${BUNDLE_BINARY} exec script/background-worker.rb start > ~/monit/worker.log 2>&1 &
echo $! > ~/monit/worker.pid

nano start-websocket.sh

#!/bin/bash
. ~/.bash_profile
cd ~/zammad
# warnung, der socket produziert relativ viel log output im normalen Betrieb ggf. anpassen
exec ${BUNDLE_BINARY} exec script/websocket-server.rb -b ${ZAMMAD_BIND_IP} -p ${ZAMMAD_WEBSOCKET_PORT} start > ~/monit/socket.log 2>&1 &
echo $! > ~/monit/socket.pid

nano stop-worker.sh

kill $( cat ~/monit/worker.pid )

nano stop-websocket.sh

kill $( cat ~/monit/socket.pid )

Das dann alles noch in der `~/.monitrc` zusammenführen (achtung einige xyz00, zammad (user) und Mail Platzhalter):

nano ~/.monitrc

set daemon 60 with start delay 10
set logfile /home/pacs/xyz00/users/zammad/monit/monit.log
set idfile /home/pacs/xyz00/users/zammad/monit/monit.id
set statefile /home/pacs/xyz00/users/zammad/monit/monit.state
set mailserver localhost
set mail-format { from: monit@your-domain.com }
#set httpd port 39008 address localhost
# allow zammadadmin:ein-monit-passwort
check process zammad_worker with pidfile /home/pacs/xyz00/users/zammad/monit/worker.pid
start program "/home/pacs/xyz00/users/zammad/monit/start-worker.sh"
stop program "/home/pacs/xyz00/users/zammad/monit/stop-worker.sh"
check process zammad_socket with pidfile /home/pacs/opa00/users/zammad/monit/socket.pid
start program "/home/pacs/xyz00/users/zammad/monit/start-websocket.sh"
stop program "/home/pacs/xyz00/users/zammad/monit/stop-websocket.sh"

Noch schnell die rechte der 4 scripts anpassen:
chmod u+x ~/monit/*.sh

Monit kann dann mit
monit
gestartet werden.

Sobald monit einmal erfolgreich anlief sollte der monit Ordner so aussehen:
ls -lh

-rw-r--r-- 1 xyz00-zammad xyz00 32 Feb 23 11:59 monit.id
-rw-r--r-- 1 xyz00-zammad xyz00 2867 Feb 24 23:46 monit.log
-rw------- 1 xyz00-zammad xyz00 800 Feb 24 13:20 monit.state
-rw-r--r-- 1 xyz00-zammad xyz00 41048 Feb 25 00:49 socket.log
-rw-r--r-- 1 xyz00-zammad xyz00 5 Feb 24 23:45 socket.pid
-rwxr--r-- 1 xyz00-zammad xyz00 209 Feb 24 23:45 start-websocket.sh
-rwxr--r-- 1 xyz00-zammad xyz00 161 Feb 24 23:27 start-worker.sh
-rwxr--r-- 1 xyz00-zammad xyz00 34 Feb 24 23:30 stop-websocket.sh
-rwxr--r-- 1 xyz00-zammad xyz00 34 Feb 23 11:53 stop-worker.sh
-rw-r--r-- 1 xyz00-zammad xyz00 0 Feb 24 23:38 worker.log
-rw-r--r-- 1 xyz00-zammad xyz00 5 Feb 24 23:38 worker.pid

== Optional: Mail-Piping ==

Um ein bisschen (viel) Last vom Background-Worker zu nehmen kann Mailpiping eingerichtet werden. Dafür sollte vermutlich zuerst der Webinstaller mit einer anderen IMAP/SMTP config durchgeklickt werden. Zusätzlich reduziert sich die Latenz von Maileingang bis Ticketeingang ein wenig.

=== Ausgangsserver auf sendmail festlegen ===

Der folgende Code schnippsel legt einen Mail-Kanal an, ohne einen dedizierten Eingang der regelmäßig abgerufen werden müsste. Quelle [https://admin-docs.zammad.org/en/latest/channels/email/advanced/sendmail.html]

rails r "Channel.create(area: 'Email::Account', options: { inbound: { adapter: 'null', options: {} }, outbound: { adapter: 'sendmail' } }, active: true, preferences: { editable: false }, updated_by_id: 1, created_by_id: 1)"

=== Maileingang per procmail ===

== Optional: Elasticsearch Anbindung ==

Weiteren User nach [[Elasticsearch]] anlegen. Dieser muss dann mit zammad verknüpft werden. Hier wird der Port 39200 angenommen.

cd ~/zammad
rails r "Setting.set('es_url', 'http://localhost:39200')"
rails r "Setting.set('es_user', 'elasticsearch')"
rails r "Setting.set('es_password', 'changeme')"

Um Elasticsearch wieder zu deaktivieren einfach die URL durch einen leeren string ersetzen.

Es wird für Zammad 5.x ein ElasticSearch 7.x benötigt. siehe auch https://docs.zammad.org/en/latest/install/elasticsearch.html

Zum ersten Einrichten, oder auch zum Testen der Verbindung:

cd ~/zammad
rake searchindex:rebuild --trace

Problem:
create indexes...rake aborted!
Can't find config setting 'es_multi_index'

Lösung:
<pre>
psql -U xyz00_zammad
INSERT INTO settings \
(title, name, description, area, frontend, created_at, updated_at) \
VALUES ('ElasticSearch Multi Index', 'es_multi_index', \
'','SearchIndex::ElasticSearch', \
false, '2023-03-15 01:00:00', '2023-03-15 01:00:00');
cd ~/zammad
rails r "Setting.set('es_multi_index', false)"
rake searchindex:rebuild --trace
</pre>

== Zammad Upgrade ==

{{Baustelle}}

<pre>
killall -u $USER
killall -u $USER 9

cp -a zammad zammad-old
cd zammad
rm -Rf app
rm -Rf public/assets
wget -O - https://ftp.zammad.com/zammad-5.3.1.tar.gz |tar -xvvz

bundle config set --local without 'test development mysql'
bundle install

Geht nicht, Ruby 2.2.5 fehlt!

cd
rbenv install 2.5.5

Geht nicht, Rbenv ist zu alt!

cd ~/.rbenv/plugins/ruby-build
git pull
cd
rbenv install 2.5.5
rbenv global 2.5.5
rbenv local 2.5.5

cd zammad
gem install bundle
gem install bundler
bundle config set --local without 'test development mysql'
bundle install

Geht nicht, Bundler 1.17.x wird gebraucht.

gem install bundler==1.17.3

Geht auch nicht.
Dann hacken wir das mal versuchsweise ins Lock.

vim Gemfile.lock

bundle config set --local without 'test development mysql'
bundle install

Es fehlen Libs.
HS bitte installieren...
[...]
Danke!

bundle config set --local without 'test development mysql'
bundle install
export RAILS_ENV=production
rake db:migrate
rake assets:clean
rake zammad:flush:cache
rake assets:precompile

/usr/bin/supervisord -c $HOME/supervisor/etc/supervisord.conf
</pre>

Nach Problemen mit Assets muss man den Dienst nochmal neustarten.

Nach dem Update testen, ob ElasticSearch noch funktioniert, eventuell muss auch ElasticSearch aktualisiert werden.

= weiterführende Links =

* [https://zammad.org/documentation Zammad Dokumentation]
* [https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/zammad Ansible Playbook für Hostsharing]

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:RubyOnRails]]
[[Kategorie:Helpdesk]]

Zammad

2024-05-14T07:31:08Z

Opa00-hostsharing: /* Installation */

== Anforderungen ==
Zammad ist ein relativ umfangreiches, mächtiges und modernes OSS Helpdesk Tool. Für die Installation wird benötigt:

* eine (Sub)Domain
* 2 bis 4 GB RAM (Schätzung, eure Erfahrung kann abweichen, je nach Nutzung)
* ruby
* nodejs
* mehrere Daemons für Hintergrunddienste (worker, websocket)
* evtl. noch ElasticSearch für Volltextsuche

== Installation ==

Die Installation orientiert sich an dieser Anleitung und wurde für zammad 6.3 verfasst.
Einige HS spezifische Abweichungen gibt es jedoch.

* https://docs.zammad.org/en/latest/install/source.html

=== User anlegen ===
Für diese Anleitung wird angenommen das der User unter dem zammad laufen soll xyz00-zammad im Packet xyz00 ist.

=== Installation ruby / ruby env ===
Prüfe die Version von ruby die zammad benötigt [https://docs.zammad.org/en/latest/prerequisites/software.html#ruby-programming-language hier].

Für diese Anleitung nehmen wir Version 3.2.3 an für zammad 6.3.

Die Installationsanleitung für rubyenv und ruby findet sich unter [[RubyRBEnv]].

Verifiziere das die Installation geklappt hat mit
ruby -v
dies sollte der herausgesuchten Versionsnummer entsprechen

=== Installation nodejs ===
Prüfe die Version von nodejs die zammad benötigt [https://docs.zammad.org/en/latest/prerequisites/software.html#node-js hier].

Für diese Anleitung nehmen wir Version 20 an für zammad 6.3.

Verifiziere das die Installation geklappt hat mit
node -v
dies sollte der herausgesuchten Versionsnummer entsprechen

=== Installation Redis ===

Siehe [[Redis]]

=== Umgebungsvariablen ===

Meine `.profile`, `.bashrc`, `.bash_profile` sahen dann wie folgt aus (möglicherweise gibt es hier optimierungspotential)

Die Datei `.bash_profile`:
. ~/.profile
. ~/.bashrc
Die Datei `.profile` (vgl instalation ruby und nodejs):
#ruby
export PATH="$HOME/.rbenv/bin:$PATH"
eval "$(rbenv init -)"
#nodejs
export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh" # This loads nvm
[ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion" # This loads nvm bash_completion
und die Datei `.bashrc`. Quellen vgl. [https://github.com/zammad/zammad/tree/develop/script/systemd/zammad.env] und [https://docs.zammad.org/en/latest/appendix/configure-env-vars.html#performance-tuning]

export REDIS_URL=redis://:<your-password-goes-here>@127.0.0.1:<port>

export RAILS_ENV=production

Dann entweder alles neu einlesen oder einmal aus und wieder einloggen. Wenn alles geklappt hat, sollten die folgenden Befehle alle sinnvolle Ausgaben liefern
echo $RAILS_ENV # Ausgabe: production
ruby -v # Ausgabe vgl. oben
nodejs -v # Ausgabe vgl. oben

=== Installation von Zammad ===
Zuerst laden wir zammad herunter, entpacken es, und installieren die dependencies (nur production)

wget -O - https://ftp.zammad.com/zammad-latest.tar.gz |tar -xvvz
cd zammad
bundle config set --local without 'test development mysql'
bundle install

Dann tragen wir die zugangsdaten der postgres Datenbank ein (auf HS Admin selbst erstellen) hier: beides `xyz00_zammad`
Mit folgendem Inhalt (Einrückung beachten!):
nano config/database.yml

# config/database.yml
production:
adapter: postgresql
host: localhost
database: xyz00_zammad
pool: 50
timeout: 5000
encoding: utf8
username: xyz00_zammad
password: changeme

Wenn alles stimmt sollten sich die folgenden Befehle ohne Fehler ausführen lassen und die Datenbanktabellen sowie die statischen Dateien zum ausliefern anlegen

rake db:migrate
rake assets:precompile

=== Zammad ausliefern ===
Um via Browser auf zammad zugreifen zu können kann es via [[Phusion Passenger]] ausgeliefert werden. Dazu muss im HS Admin eine Domain aufgeschaltet werden. Dann wird:
* die .htaccess wie folgend gesetzt werden
* der zammad ordner nach app-ssl gelinkt werden
* und der statische content in htdocs-ssl
* Optional kann das Domain Template noch um die subdomains bereinigt werden (2. Befehl)

cd ~/doms/zammad.example.org/
rm -r subs*
rm -r htdocs-ssl
rm -r app-ssl
ln -s ~/zammad app-ssl
ln -s ~/zammad/public htdocs-ssl
nano .htaccess

# Inhalt .htaccess
#PassengerFriendlyErrorPages on # falls nötig zum debuggen einkommentieren
RackEnv production
RailsEnv production
PassengerRuby /home/pacs/xyz00/users/zammad/.rbenv/shims/ruby
# local websocket ssl forwarding
RewriteCond %{HTTP:Connection} Upgrade [NC]
RewriteCond %{HTTP:Upgrade} websocket [NC]
RewriteRule /(.*) ws://127.0.0.1:6042/$1 [P,L]

Wenn alles geklappt hat sollte auf der Domain das restliche Web-basierte Setup zu sehen sein. Dort muss dann auch der andere HS Postfach User eingetragen werden. Theoretisch könnte man das auf dem gleichen Account abwickeln, ich persönlich würde es allerdings trennen. Piping wie bei manch andren Mailbasierten Anwendungen scheint nicht so einfach möglich zu sein (needs more investigation)

=== Hintergrunddienste ===

Damit der Websocket-Server und der Hintergrund Worker ordentlich laufen müssen folgende Befehle ausgeführt werden. Die IP Adresse und der Port beim Socket werden aus den Enviroment Variablen von oben bezogen, können allerdings auch manuell gesetzt werden.
cd zammad
bundle exec script/background-worker.rb start
bundle exec script/websocket-server.rb -b ${ZAMMAD_BIND_IP} -p ${ZAMMAD_WEBSOCKET_PORT} start

== Empfohlen: Monit ==
Ich habe alles monit spezifische in den ordner monit gepackt
cd
mkdir monit
cd monit
Zum starten habe ich ein kleines start und stop script (für monit) erstellt (lange zeile ggf. beachten)

nano start-worker.sh

#!/bin/bash
. ~/.bash_profile
cd ~/zammad
exec ${BUNDLE_BINARY} exec script/background-worker.rb start > ~/monit/worker.log 2>&1 &
echo $! > ~/monit/worker.pid

nano start-websocket.sh

#!/bin/bash
. ~/.bash_profile
cd ~/zammad
# warnung, der socket produziert relativ viel log output im normalen Betrieb ggf. anpassen
exec ${BUNDLE_BINARY} exec script/websocket-server.rb -b ${ZAMMAD_BIND_IP} -p ${ZAMMAD_WEBSOCKET_PORT} start > ~/monit/socket.log 2>&1 &
echo $! > ~/monit/socket.pid

nano stop-worker.sh

kill $( cat ~/monit/worker.pid )

nano stop-websocket.sh

kill $( cat ~/monit/socket.pid )

Das dann alles noch in der `~/.monitrc` zusammenführen (achtung einige xyz00, zammad (user) und Mail Platzhalter):

nano ~/.monitrc

set daemon 60 with start delay 10
set logfile /home/pacs/xyz00/users/zammad/monit/monit.log
set idfile /home/pacs/xyz00/users/zammad/monit/monit.id
set statefile /home/pacs/xyz00/users/zammad/monit/monit.state
set mailserver localhost
set mail-format { from: monit@your-domain.com }
#set httpd port 39008 address localhost
# allow zammadadmin:ein-monit-passwort
check process zammad_worker with pidfile /home/pacs/xyz00/users/zammad/monit/worker.pid
start program "/home/pacs/xyz00/users/zammad/monit/start-worker.sh"
stop program "/home/pacs/xyz00/users/zammad/monit/stop-worker.sh"
check process zammad_socket with pidfile /home/pacs/opa00/users/zammad/monit/socket.pid
start program "/home/pacs/xyz00/users/zammad/monit/start-websocket.sh"
stop program "/home/pacs/xyz00/users/zammad/monit/stop-websocket.sh"

Noch schnell die rechte der 4 scripts anpassen:
chmod u+x ~/monit/*.sh

Monit kann dann mit
monit
gestartet werden.

Sobald monit einmal erfolgreich anlief sollte der monit Ordner so aussehen:
ls -lh

-rw-r--r-- 1 xyz00-zammad xyz00 32 Feb 23 11:59 monit.id
-rw-r--r-- 1 xyz00-zammad xyz00 2867 Feb 24 23:46 monit.log
-rw------- 1 xyz00-zammad xyz00 800 Feb 24 13:20 monit.state
-rw-r--r-- 1 xyz00-zammad xyz00 41048 Feb 25 00:49 socket.log
-rw-r--r-- 1 xyz00-zammad xyz00 5 Feb 24 23:45 socket.pid
-rwxr--r-- 1 xyz00-zammad xyz00 209 Feb 24 23:45 start-websocket.sh
-rwxr--r-- 1 xyz00-zammad xyz00 161 Feb 24 23:27 start-worker.sh
-rwxr--r-- 1 xyz00-zammad xyz00 34 Feb 24 23:30 stop-websocket.sh
-rwxr--r-- 1 xyz00-zammad xyz00 34 Feb 23 11:53 stop-worker.sh
-rw-r--r-- 1 xyz00-zammad xyz00 0 Feb 24 23:38 worker.log
-rw-r--r-- 1 xyz00-zammad xyz00 5 Feb 24 23:38 worker.pid

== Optional: Mail-Piping ==

Um ein bisschen (viel) Last vom Background-Worker zu nehmen kann Mailpiping eingerichtet werden. Dafür sollte vermutlich zuerst der Webinstaller mit einer anderen IMAP/SMTP config durchgeklickt werden. Zusätzlich reduziert sich die Latenz von Maileingang bis Ticketeingang ein wenig.

=== Ausgangsserver auf sendmail festlegen ===

Der folgende Code schnippsel legt einen Mail-Kanal an, ohne einen dedizierten Eingang der regelmäßig abgerufen werden müsste. Quelle [https://admin-docs.zammad.org/en/latest/channels/email/advanced/sendmail.html]

rails r "Channel.create(area: 'Email::Account', options: { inbound: { adapter: 'null', options: {} }, outbound: { adapter: 'sendmail' } }, active: true, preferences: { editable: false }, updated_by_id: 1, created_by_id: 1)"

=== Maileingang per procmail ===

== Optional: Elasticsearch Anbindung ==

Weiteren User nach [[Elasticsearch]] anlegen. Dieser muss dann mit zammad verknüpft werden. Hier wird der Port 39200 angenommen.

cd ~/zammad
rails r "Setting.set('es_url', 'http://localhost:39200')"
rails r "Setting.set('es_user', 'elasticsearch')"
rails r "Setting.set('es_password', 'changeme')"

Um Elasticsearch wieder zu deaktivieren einfach die URL durch einen leeren string ersetzen.

Es wird für Zammad 5.x ein ElasticSearch 7.x benötigt. siehe auch https://docs.zammad.org/en/latest/install/elasticsearch.html

Zum ersten Einrichten, oder auch zum Testen der Verbindung:

cd ~/zammad
rake searchindex:rebuild --trace

Problem:
create indexes...rake aborted!
Can't find config setting 'es_multi_index'

Lösung:
<pre>
psql -U xyz00_zammad
INSERT INTO settings \
(title, name, description, area, frontend, created_at, updated_at) \
VALUES ('ElasticSearch Multi Index', 'es_multi_index', \
'','SearchIndex::ElasticSearch', \
false, '2023-03-15 01:00:00', '2023-03-15 01:00:00');
cd ~/zammad
rails r "Setting.set('es_multi_index', false)"
rake searchindex:rebuild --trace
</pre>

== Zammad Upgrade ==

{{Baustelle}}

<pre>
killall -u $USER
killall -u $USER 9

cp -a zammad zammad-old
cd zammad
rm -Rf app
rm -Rf public/assets
wget -O - https://ftp.zammad.com/zammad-5.3.1.tar.gz |tar -xvvz

bundle config set --local without 'test development mysql'
bundle install

Geht nicht, Ruby 2.2.5 fehlt!

cd
rbenv install 2.5.5

Geht nicht, Rbenv ist zu alt!

cd ~/.rbenv/plugins/ruby-build
git pull
cd
rbenv install 2.5.5
rbenv global 2.5.5
rbenv local 2.5.5

cd zammad
gem install bundle
gem install bundler
bundle config set --local without 'test development mysql'
bundle install

Geht nicht, Bundler 1.17.x wird gebraucht.

gem install bundler==1.17.3

Geht auch nicht.
Dann hacken wir das mal versuchsweise ins Lock.

vim Gemfile.lock

bundle config set --local without 'test development mysql'
bundle install

Es fehlen Libs.
HS bitte installieren...
[...]
Danke!

bundle config set --local without 'test development mysql'
bundle install
export RAILS_ENV=production
rake db:migrate
rake assets:clean
rake zammad:flush:cache
rake assets:precompile

/usr/bin/supervisord -c $HOME/supervisor/etc/supervisord.conf
</pre>

Nach Problemen mit Assets muss man den Dienst nochmal neustarten.

Nach dem Update testen, ob ElasticSearch noch funktioniert, eventuell muss auch ElasticSearch aktualisiert werden.

= weiterführende Links =

* [https://zammad.org/documentation Zammad Dokumentation]
* [https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/zammad Ansible Playbook für Hostsharing]

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:RubyOnRails]]
[[Kategorie:Helpdesk]]

Zammad

2024-05-14T07:24:48Z

Opa00-hostsharing: /* Installation */

== Anforderungen ==
Zammad ist ein relativ umfangreiches, mächtiges und modernes OSS Helpdesk Tool. Für die Installation wird benötigt:

* eine (Sub)Domain
* 2 bis 4 GB RAM (Schätzung, eure Erfahrung kann abweichen, je nach Nutzung)
* ruby
* nodejs
* mehrere Daemons für Hintergrunddienste (worker, websocket)
* evtl. noch ElasticSearch für Volltextsuche

== Installation ==

Die Installation orientiert sich an dieser Anleitung und wurde für zammad 6.3 verfasst.
Einige HS spezifische Abweichungen gibt es jedoch.

* https://docs.zammad.org/en/latest/install/source.html

=== User anlegen ===
Für diese Anleitung wird angenommen das der User unter dem zammad laufen soll xyz00-zammad im Packet xyz00 ist.

=== Installation ruby / ruby env ===
Prüfe die Version von ruby die zammad benötigt [https://docs.zammad.org/en/latest/prerequisites/software.html#ruby-programming-language hier].

Für diese Anleitung nehmen wir Version 3.2.3 an für zammad 6.3.

Die Installationsanleitung für rubyenv und ruby findet sich unter [[RubyRBEnv]].

Verifiziere das die Installation geklappt hat mit
ruby -v
dies sollte der herausgesuchten Versionsnummer entsprechen

=== Installation nodejs ===
Prüfe die Version von nodejs die zammad benötigt [https://docs.zammad.org/en/latest/prerequisites/software.html#node-js hier].

Für diese Anleitung nehmen wir Version 20 an für zammad 6.3.

Verifiziere das die Installation geklappt hat mit
node -v
dies sollte der herausgesuchten Versionsnummer entsprechen

=== Umgebungsvariablen ===

Meine `.profile`, `.bashrc`, `.bash_profile` sahen dann wie folgt aus (möglicherweise gibt es hier optimierungspotential)

Die Datei `.bash_profile`:
. ~/.profile
. ~/.bashrc
Die Datei `.profile` (vgl instalation ruby und nodejs):
#ruby
export PATH="$HOME/.rbenv/bin:$PATH"
eval "$(rbenv init -)"
#nodejs
export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh" # This loads nvm
[ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion" # This loads nvm bash_completion
und die Datei `.bashrc`. Quellen vgl. [https://github.com/zammad/zammad/tree/develop/script/systemd/zammad.env] und [https://docs.zammad.org/en/latest/appendix/configure-env-vars.html#performance-tuning]
# zammad env config
WEB_CONCURRENCY=4
# service config
BUNDLE_BINARY=bundle
RAILS_ENV=production
ZAMMAD_BIND_IP=127.0.0.1
ZAMMAD_RAILS_PORT=3000
ZAMMAD_WEBSOCKET_PORT=6042

Dann entweder alles neu einlesen oder einmal aus und wieder einloggen. Wenn alles geklappt hat, sollten die folgenden Befehle alle sinnvolle Ausgaben liefern
echo $RAILS_ENV # Ausgabe: production
ruby -v # Ausgabe vgl. oben
nodejs -v # Ausgabe vgl. oben

=== Installation von Zammad ===
Zuerst laden wir zammad herunter, entpacken es, und installieren die dependencies (nur production)

wget -O - https://ftp.zammad.com/zammad-latest.tar.gz |tar -xvvz
cd zammad
bundle config set --local without 'test development mysql'
bundle install

Dann tragen wir die zugangsdaten der postgres Datenbank ein (auf HS Admin selbst erstellen) hier: beides `xyz00_zammad`
Mit folgendem Inhalt (Einrückung beachten!):
nano config/database.yml

# config/database.yml
production:
adapter: postgresql
host: localhost
database: xyz00_zammad
pool: 50
timeout: 5000
encoding: utf8
username: xyz00_zammad
password: changeme

Wenn alles stimmt sollten sich die folgenden Befehle ohne Fehler ausführen lassen und die Datenbanktabellen sowie die statischen Dateien zum ausliefern anlegen

rake db:migrate
rake assets:precompile

=== Zammad ausliefern ===
Um via Browser auf zammad zugreifen zu können kann es via [[Phusion Passenger]] ausgeliefert werden. Dazu muss im HS Admin eine Domain aufgeschaltet werden. Dann wird:
* die .htaccess wie folgend gesetzt werden
* der zammad ordner nach app-ssl gelinkt werden
* und der statische content in htdocs-ssl
* Optional kann das Domain Template noch um die subdomains bereinigt werden (2. Befehl)

cd ~/doms/zammad.example.org/
rm -r subs*
rm -r htdocs-ssl
rm -r app-ssl
ln -s ~/zammad app-ssl
ln -s ~/zammad/public htdocs-ssl
nano .htaccess

# Inhalt .htaccess
#PassengerFriendlyErrorPages on # falls nötig zum debuggen einkommentieren
RackEnv production
RailsEnv production
PassengerRuby /home/pacs/xyz00/users/zammad/.rbenv/shims/ruby
# local websocket ssl forwarding
RewriteCond %{HTTP:Connection} Upgrade [NC]
RewriteCond %{HTTP:Upgrade} websocket [NC]
RewriteRule /(.*) ws://127.0.0.1:6042/$1 [P,L]

Wenn alles geklappt hat sollte auf der Domain das restliche Web-basierte Setup zu sehen sein. Dort muss dann auch der andere HS Postfach User eingetragen werden. Theoretisch könnte man das auf dem gleichen Account abwickeln, ich persönlich würde es allerdings trennen. Piping wie bei manch andren Mailbasierten Anwendungen scheint nicht so einfach möglich zu sein (needs more investigation)

=== Hintergrunddienste ===

Damit der Websocket-Server und der Hintergrund Worker ordentlich laufen müssen folgende Befehle ausgeführt werden. Die IP Adresse und der Port beim Socket werden aus den Enviroment Variablen von oben bezogen, können allerdings auch manuell gesetzt werden.
cd zammad
bundle exec script/background-worker.rb start
bundle exec script/websocket-server.rb -b ${ZAMMAD_BIND_IP} -p ${ZAMMAD_WEBSOCKET_PORT} start

== Empfohlen: Monit ==
Ich habe alles monit spezifische in den ordner monit gepackt
cd
mkdir monit
cd monit
Zum starten habe ich ein kleines start und stop script (für monit) erstellt (lange zeile ggf. beachten)

nano start-worker.sh

#!/bin/bash
. ~/.bash_profile
cd ~/zammad
exec ${BUNDLE_BINARY} exec script/background-worker.rb start > ~/monit/worker.log 2>&1 &
echo $! > ~/monit/worker.pid

nano start-websocket.sh

#!/bin/bash
. ~/.bash_profile
cd ~/zammad
# warnung, der socket produziert relativ viel log output im normalen Betrieb ggf. anpassen
exec ${BUNDLE_BINARY} exec script/websocket-server.rb -b ${ZAMMAD_BIND_IP} -p ${ZAMMAD_WEBSOCKET_PORT} start > ~/monit/socket.log 2>&1 &
echo $! > ~/monit/socket.pid

nano stop-worker.sh

kill $( cat ~/monit/worker.pid )

nano stop-websocket.sh

kill $( cat ~/monit/socket.pid )

Das dann alles noch in der `~/.monitrc` zusammenführen (achtung einige xyz00, zammad (user) und Mail Platzhalter):

nano ~/.monitrc

set daemon 60 with start delay 10
set logfile /home/pacs/xyz00/users/zammad/monit/monit.log
set idfile /home/pacs/xyz00/users/zammad/monit/monit.id
set statefile /home/pacs/xyz00/users/zammad/monit/monit.state
set mailserver localhost
set mail-format { from: monit@your-domain.com }
#set httpd port 39008 address localhost
# allow zammadadmin:ein-monit-passwort
check process zammad_worker with pidfile /home/pacs/xyz00/users/zammad/monit/worker.pid
start program "/home/pacs/xyz00/users/zammad/monit/start-worker.sh"
stop program "/home/pacs/xyz00/users/zammad/monit/stop-worker.sh"
check process zammad_socket with pidfile /home/pacs/opa00/users/zammad/monit/socket.pid
start program "/home/pacs/xyz00/users/zammad/monit/start-websocket.sh"
stop program "/home/pacs/xyz00/users/zammad/monit/stop-websocket.sh"

Noch schnell die rechte der 4 scripts anpassen:
chmod u+x ~/monit/*.sh

Monit kann dann mit
monit
gestartet werden.

Sobald monit einmal erfolgreich anlief sollte der monit Ordner so aussehen:
ls -lh

-rw-r--r-- 1 xyz00-zammad xyz00 32 Feb 23 11:59 monit.id
-rw-r--r-- 1 xyz00-zammad xyz00 2867 Feb 24 23:46 monit.log
-rw------- 1 xyz00-zammad xyz00 800 Feb 24 13:20 monit.state
-rw-r--r-- 1 xyz00-zammad xyz00 41048 Feb 25 00:49 socket.log
-rw-r--r-- 1 xyz00-zammad xyz00 5 Feb 24 23:45 socket.pid
-rwxr--r-- 1 xyz00-zammad xyz00 209 Feb 24 23:45 start-websocket.sh
-rwxr--r-- 1 xyz00-zammad xyz00 161 Feb 24 23:27 start-worker.sh
-rwxr--r-- 1 xyz00-zammad xyz00 34 Feb 24 23:30 stop-websocket.sh
-rwxr--r-- 1 xyz00-zammad xyz00 34 Feb 23 11:53 stop-worker.sh
-rw-r--r-- 1 xyz00-zammad xyz00 0 Feb 24 23:38 worker.log
-rw-r--r-- 1 xyz00-zammad xyz00 5 Feb 24 23:38 worker.pid

== Optional: Mail-Piping ==

Um ein bisschen (viel) Last vom Background-Worker zu nehmen kann Mailpiping eingerichtet werden. Dafür sollte vermutlich zuerst der Webinstaller mit einer anderen IMAP/SMTP config durchgeklickt werden. Zusätzlich reduziert sich die Latenz von Maileingang bis Ticketeingang ein wenig.

=== Ausgangsserver auf sendmail festlegen ===

Der folgende Code schnippsel legt einen Mail-Kanal an, ohne einen dedizierten Eingang der regelmäßig abgerufen werden müsste. Quelle [https://admin-docs.zammad.org/en/latest/channels/email/advanced/sendmail.html]

rails r "Channel.create(area: 'Email::Account', options: { inbound: { adapter: 'null', options: {} }, outbound: { adapter: 'sendmail' } }, active: true, preferences: { editable: false }, updated_by_id: 1, created_by_id: 1)"

=== Maileingang per procmail ===

== Optional: Elasticsearch Anbindung ==

Weiteren User nach [[Elasticsearch]] anlegen. Dieser muss dann mit zammad verknüpft werden. Hier wird der Port 39200 angenommen.

cd ~/zammad
rails r "Setting.set('es_url', 'http://localhost:39200')"
rails r "Setting.set('es_user', 'elasticsearch')"
rails r "Setting.set('es_password', 'changeme')"

Um Elasticsearch wieder zu deaktivieren einfach die URL durch einen leeren string ersetzen.

Es wird für Zammad 5.x ein ElasticSearch 7.x benötigt. siehe auch https://docs.zammad.org/en/latest/install/elasticsearch.html

Zum ersten Einrichten, oder auch zum Testen der Verbindung:

cd ~/zammad
rake searchindex:rebuild --trace

Problem:
create indexes...rake aborted!
Can't find config setting 'es_multi_index'

Lösung:
<pre>
psql -U xyz00_zammad
INSERT INTO settings \
(title, name, description, area, frontend, created_at, updated_at) \
VALUES ('ElasticSearch Multi Index', 'es_multi_index', \
'','SearchIndex::ElasticSearch', \
false, '2023-03-15 01:00:00', '2023-03-15 01:00:00');
cd ~/zammad
rails r "Setting.set('es_multi_index', false)"
rake searchindex:rebuild --trace
</pre>

== Zammad Upgrade ==

{{Baustelle}}

<pre>
killall -u $USER
killall -u $USER 9

cp -a zammad zammad-old
cd zammad
rm -Rf app
rm -Rf public/assets
wget -O - https://ftp.zammad.com/zammad-5.3.1.tar.gz |tar -xvvz

bundle config set --local without 'test development mysql'
bundle install

Geht nicht, Ruby 2.2.5 fehlt!

cd
rbenv install 2.5.5

Geht nicht, Rbenv ist zu alt!

cd ~/.rbenv/plugins/ruby-build
git pull
cd
rbenv install 2.5.5
rbenv global 2.5.5
rbenv local 2.5.5

cd zammad
gem install bundle
gem install bundler
bundle config set --local without 'test development mysql'
bundle install

Geht nicht, Bundler 1.17.x wird gebraucht.

gem install bundler==1.17.3

Geht auch nicht.
Dann hacken wir das mal versuchsweise ins Lock.

vim Gemfile.lock

bundle config set --local without 'test development mysql'
bundle install

Es fehlen Libs.
HS bitte installieren...
[...]
Danke!

bundle config set --local without 'test development mysql'
bundle install
export RAILS_ENV=production
rake db:migrate
rake assets:clean
rake zammad:flush:cache
rake assets:precompile

/usr/bin/supervisord -c $HOME/supervisor/etc/supervisord.conf
</pre>

Nach Problemen mit Assets muss man den Dienst nochmal neustarten.

Nach dem Update testen, ob ElasticSearch noch funktioniert, eventuell muss auch ElasticSearch aktualisiert werden.

= weiterführende Links =

* [https://zammad.org/documentation Zammad Dokumentation]
* [https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/zammad Ansible Playbook für Hostsharing]

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:RubyOnRails]]
[[Kategorie:Helpdesk]]

Helfertool

2024-05-10T17:08:07Z

Opa00-hostsharing: /* Inbetriebnahme */

== Helfertool.org ==

Helfertool ist eine Software, die es erlaubt, die Freiwilligen oder Mitarbeiter für eine Veranstaltung zu verwalten. Sie können sich online für Jobs registrieren und die Verwaltungsoberfläche erlaubt es, die registrierten Personen zu verwalten. Für jeden Job können verschiedene Schichten mit einer Start- und Endzeit und einer begrenzten Anzahl von Helfern erstellt werden.

Sie ist in Python mit Django geschrieben.

Features lt Website:
* Entscheiden Sie, ob die Registrierung für eine Stelle intern oder öffentlich sichtbar ist.
* Generieren Sie Ausweise zur Identifizierung und Zugangskontrolle.
* Verwaltung von Geschenken für Freiwillige: sie können für jede geleistete Schicht ein Geschenk erhalten, die Organisatoren können vermerken, ob ein Freiwilliger das Geschenk für jede einzelne Schicht erhalten hat.
* Verwaltung von Geschenken für Freiwillige: sie können für jede geleistete Schicht ein Geschenk erhalten, die Organisatoren können vermerken, ob ein Freiwilliger das Geschenk für jede einzelne Schicht erhalten hat.

Mehr Infos auf https://www.helfertool.org

=== Installation ===
Zuerst das git repo clonen. Ggf. Versionsnummer auf die aktuelle Version anpassen.

git clone --single-branch https://github.com/helfertool/helfertool/

Aktuell wird laut src/requirements.txt ein Django in Version 4.2 benötigt.

Aktuell wird dafür

Python 3.8, 3.9, 3.10, 3.11, and 3.12 (as of 4.2. 8)

unterstützt. Auf den debian bookworm Maschinen sollte daher das installierte python3 genügen

python3 --version
Python 3.11.2

Vom Helfertool Docker wird aktuell auch Version 3.11 eingesetzt, nachzusehen in deployment/container/etc/uwsgi.conf

Falls das auf deiner Maschine nicht der Fall ist siehe [[Python]] für die manuelle Installation einer aktuelleren Version.

Wir installieren zuerst die Dependencies, dafür legen wir uns ein venv an um diese nur lokal zu laden.

cd ~
python3 -m venv venv-ht # initalisierung des venv venv-ht
source ~/venv-ht/bin/activate # aktivierung des venv
# installation der dependencies im venv (wichtig! venv-ht muss geladen sein!)
cd helfertool
pip install -r src/requirements.txt -r src/requirements_prod.txt

Für den persönlichen Komfort habe ich folgende Zeilen in der ~/.profile hinterlegt.

source ~/venv-ht/bin/activate

=== Konfiguration ===

Die Config Datei findet sich unter ~/helfertool/src/helfertool.yml

Dort muss insbesondere der Datenbankzugang hinterlegt werden, die Domain bei Allowed Hosts und die E-Mail

ob alles geklappt hat kann mit den folgenden befehlen indirekt getestet werden

python ~/helfertool/src/manage.py migrate
python ~/helfertool/src/manage.py createcachetable
python ~/helfertool/src/manage.py loaddata toolsettings

=== Inbetriebnahme ===

cd ~/helfertool
python src/manage.py collectstatic --noinput
python src/manage.py compress

Der neue Erzeugte static ordner wird der htdocs-ssl ordner in der Entsprechenden Domain:

cd ~/doms/example.org/htdocs-ssl
rm .htaccess
ln -s ~/helfertool/static
ln -s ~/helfertool/media

Es sollten dann 2 Links (static und media) in htdocs-ssl liegen die auf die jeweiligen Ordner im git zeigen.

Der statische Assetornder halt leider jedoch nich by default die Rechte die Hostsharing braucht, das korrigieren für die Dateien und Ornder jeweils wir mit:

cd ~/helfertool
find static/ -type f -exec chmod 644 {} \;
find static/ -type d -exec chmod 755 {} \;

Leider werden neue hochgeladene Inhalte per default auch mit falschen Permissons angelegt. Das lässt sich fixen indem man folgende Datei ändert. Folgend der geänderte Inhalt:

~/helfertool/src/helfertool/settings.py

# file permissions for newly uploaded files and directories
FILE_UPLOAD_PERMISSIONS = 0o644
FILE_UPLOAD_DIRECTORY_PERMISSIONS = 0o755

um die Python Anwendung mit Passenger auszuliefern sind jetzt noch 2 Schritte nötig:

Eine htaccess Datei im Domain Ordner app-ssl hinterlegen mit dem Inhalt:
SetEnv PYTHONPATH "/home/pacs/opa02/users/helfertool/helfertool/src"
und die wsgi datei in app-ssl hinterlegen:

ln -s ~/helfertool/src/helfertool/wsgi.py ~/doms/example.com/app-ssl/passenger_wsgi.py

Zusätzlich noch im HS Admin den Pfad zum venv hinterlegen

Zum Neustart der Anwendung (z.B. um config neu einzulesen) kann der Befehl

passenger-config restart-app

verwendet werden

=== Customization ===

Wenn du, wie wir, dieses sehr gute Grün durch eine andere Farbe ersetzen willst kannst du wie folgt vorgehen:

Das zu ersetzende CSS findest du unter <code>~/helfertool/static/compressed/css/</code> mit dem Dateinamen main.<langezahlenfolge>.css diese Datei muss ersetzt werden. Am einfachsten geht das wie folgt:

cd ~/helfertool/static/helfertool/theme
# dort z.b. die Farben ändern
nano _colors.scss
# ggf. noch weitere Änderungen vornehmen
# ...
# compilieren
scss helfertool.scss ../../compressed/main.x.css

In dem o.g. compressed Ordner findet sich dann die neue passende Datei main.x.css, diese einfach über die alte Datei mit der kryptischen Nummer drüber kopieren. Das war es schon :)

Ungetestet: ggf. kann das compilieren auch mit python ~/helfertool/src/manage.py compress ausgelöst werden

Helfertool

2024-05-10T17:04:18Z

Opa00-hostsharing: /* Inbetriebnahme */

== Helfertool.org ==

Helfertool ist eine Software, die es erlaubt, die Freiwilligen oder Mitarbeiter für eine Veranstaltung zu verwalten. Sie können sich online für Jobs registrieren und die Verwaltungsoberfläche erlaubt es, die registrierten Personen zu verwalten. Für jeden Job können verschiedene Schichten mit einer Start- und Endzeit und einer begrenzten Anzahl von Helfern erstellt werden.

Sie ist in Python mit Django geschrieben.

Features lt Website:
* Entscheiden Sie, ob die Registrierung für eine Stelle intern oder öffentlich sichtbar ist.
* Generieren Sie Ausweise zur Identifizierung und Zugangskontrolle.
* Verwaltung von Geschenken für Freiwillige: sie können für jede geleistete Schicht ein Geschenk erhalten, die Organisatoren können vermerken, ob ein Freiwilliger das Geschenk für jede einzelne Schicht erhalten hat.
* Verwaltung von Geschenken für Freiwillige: sie können für jede geleistete Schicht ein Geschenk erhalten, die Organisatoren können vermerken, ob ein Freiwilliger das Geschenk für jede einzelne Schicht erhalten hat.

Mehr Infos auf https://www.helfertool.org

=== Installation ===
Zuerst das git repo clonen. Ggf. Versionsnummer auf die aktuelle Version anpassen.

git clone --single-branch https://github.com/helfertool/helfertool/

Aktuell wird laut src/requirements.txt ein Django in Version 4.2 benötigt.

Aktuell wird dafür

Python 3.8, 3.9, 3.10, 3.11, and 3.12 (as of 4.2. 8)

unterstützt. Auf den debian bookworm Maschinen sollte daher das installierte python3 genügen

python3 --version
Python 3.11.2

Vom Helfertool Docker wird aktuell auch Version 3.11 eingesetzt, nachzusehen in deployment/container/etc/uwsgi.conf

Falls das auf deiner Maschine nicht der Fall ist siehe [[Python]] für die manuelle Installation einer aktuelleren Version.

Wir installieren zuerst die Dependencies, dafür legen wir uns ein venv an um diese nur lokal zu laden.

cd ~
python3 -m venv venv-ht # initalisierung des venv venv-ht
source ~/venv-ht/bin/activate # aktivierung des venv
# installation der dependencies im venv (wichtig! venv-ht muss geladen sein!)
cd helfertool
pip install -r src/requirements.txt -r src/requirements_prod.txt

Für den persönlichen Komfort habe ich folgende Zeilen in der ~/.profile hinterlegt.

source ~/venv-ht/bin/activate

=== Konfiguration ===

Die Config Datei findet sich unter ~/helfertool/src/helfertool.yml

Dort muss insbesondere der Datenbankzugang hinterlegt werden, die Domain bei Allowed Hosts und die E-Mail

ob alles geklappt hat kann mit den folgenden befehlen indirekt getestet werden

python ~/helfertool/src/manage.py migrate
python ~/helfertool/src/manage.py createcachetable
python ~/helfertool/src/manage.py loaddata toolsettings

=== Inbetriebnahme ===

cd ~/helfertool
python src/manage.py collectstatic --noinput
python src/manage.py compress

Der neue Erzeugte static ordner wird der htdocs-ssl ordner in der Entsprechenden Domain:

cd ~/doms/example.org/htdocs-ssl
rm .htaccess
ln -s ~/helfertool/static
ln -s ~/helfertool/media

Es sollten dann 2 Links (static und media) in htdocs-ssl liegen die auf die jeweiligen Ordner im git zeigen.

Der statische Assetornder halt leider jedoch nich by default die Rechte die Hostsharing braucht, das korrigieren für die Dateien und Ornder jeweils wir mit:

cd ~/helfertool
find static/ -type f -exec chmod 644 {} \;
find static/ -type d -exec chmod 755 {} \;

Leider werden neue hochgeladene Inhalte per default auch mit falschen Permissons angelegt. Das lässt sich fixen indem man folgende Datei ändert. Folgend der geänderte Inhalt:

~/helfertool/src/helfertool/settings.py

# file permissions for newly uploaded files and directories
FILE_UPLOAD_PERMISSIONS = 0o644
FILE_UPLOAD_DIRECTORY_PERMISSIONS = 0o755

um die Python Anwendung mit Passenger auszuliefern sind jetzt noch 2 Schritte nötig:

Eine htaccess Datei im Domain Ordner app-ssl hinterlegen mit dem Inhalt:
SetEnv PYTHONPATH "/home/pacs/opa02/users/helfertool/helfertool/src"
und die wsgi datei in app-ssl hinterlegen:

ln -s ~/helfertool/src/helfertool/wsgi.py ~/doms/example.com/app-ssl/passenger_wsgi.py

Zusätzlich noch im HS Admin den Pfad zum venv hinterlegen

=== Customization ===

Wenn du, wie wir, dieses sehr gute Grün durch eine andere Farbe ersetzen willst kannst du wie folgt vorgehen:

Das zu ersetzende CSS findest du unter <code>~/helfertool/static/compressed/css/</code> mit dem Dateinamen main.<langezahlenfolge>.css diese Datei muss ersetzt werden. Am einfachsten geht das wie folgt:

cd ~/helfertool/static/helfertool/theme
# dort z.b. die Farben ändern
nano _colors.scss
# ggf. noch weitere Änderungen vornehmen
# ...
# compilieren
scss helfertool.scss ../../compressed/main.x.css

In dem o.g. compressed Ordner findet sich dann die neue passende Datei main.x.css, diese einfach über die alte Datei mit der kryptischen Nummer drüber kopieren. Das war es schon :)

Ungetestet: ggf. kann das compilieren auch mit python ~/helfertool/src/manage.py compress ausgelöst werden

Helfertool

2024-05-10T17:03:50Z

Opa00-hostsharing: /* Customization */

== Helfertool.org ==

Helfertool ist eine Software, die es erlaubt, die Freiwilligen oder Mitarbeiter für eine Veranstaltung zu verwalten. Sie können sich online für Jobs registrieren und die Verwaltungsoberfläche erlaubt es, die registrierten Personen zu verwalten. Für jeden Job können verschiedene Schichten mit einer Start- und Endzeit und einer begrenzten Anzahl von Helfern erstellt werden.

Sie ist in Python mit Django geschrieben.

Features lt Website:
* Entscheiden Sie, ob die Registrierung für eine Stelle intern oder öffentlich sichtbar ist.
* Generieren Sie Ausweise zur Identifizierung und Zugangskontrolle.
* Verwaltung von Geschenken für Freiwillige: sie können für jede geleistete Schicht ein Geschenk erhalten, die Organisatoren können vermerken, ob ein Freiwilliger das Geschenk für jede einzelne Schicht erhalten hat.
* Verwaltung von Geschenken für Freiwillige: sie können für jede geleistete Schicht ein Geschenk erhalten, die Organisatoren können vermerken, ob ein Freiwilliger das Geschenk für jede einzelne Schicht erhalten hat.

Mehr Infos auf https://www.helfertool.org

=== Installation ===
Zuerst das git repo clonen. Ggf. Versionsnummer auf die aktuelle Version anpassen.

git clone --single-branch https://github.com/helfertool/helfertool/

Aktuell wird laut src/requirements.txt ein Django in Version 4.2 benötigt.

Aktuell wird dafür

Python 3.8, 3.9, 3.10, 3.11, and 3.12 (as of 4.2. 8)

unterstützt. Auf den debian bookworm Maschinen sollte daher das installierte python3 genügen

python3 --version
Python 3.11.2

Vom Helfertool Docker wird aktuell auch Version 3.11 eingesetzt, nachzusehen in deployment/container/etc/uwsgi.conf

Falls das auf deiner Maschine nicht der Fall ist siehe [[Python]] für die manuelle Installation einer aktuelleren Version.

Wir installieren zuerst die Dependencies, dafür legen wir uns ein venv an um diese nur lokal zu laden.

cd ~
python3 -m venv venv-ht # initalisierung des venv venv-ht
source ~/venv-ht/bin/activate # aktivierung des venv
# installation der dependencies im venv (wichtig! venv-ht muss geladen sein!)
cd helfertool
pip install -r src/requirements.txt -r src/requirements_prod.txt

Für den persönlichen Komfort habe ich folgende Zeilen in der ~/.profile hinterlegt.

source ~/venv-ht/bin/activate

=== Konfiguration ===

Die Config Datei findet sich unter ~/helfertool/src/helfertool.yml

Dort muss insbesondere der Datenbankzugang hinterlegt werden, die Domain bei Allowed Hosts und die E-Mail

ob alles geklappt hat kann mit den folgenden befehlen indirekt getestet werden

python ~/helfertool/src/manage.py migrate
python ~/helfertool/src/manage.py createcachetable
python ~/helfertool/src/manage.py loaddata toolsettings

=== Inbetriebnahme ===

cd ~/helfertool
python src/manage.py collectstatic --noinput

Der neue Erzeugte static ordner wird der htdocs-ssl ordner in der Entsprechenden Domain:

cd ~/doms/example.org/htdocs-ssl
rm .htaccess
ln -s ~/helfertool/static
ln -s ~/helfertool/media

Es sollten dann 2 Links (static und media) in htdocs-ssl liegen die auf die jeweiligen Ordner im git zeigen.

Der statische Assetornder halt leider jedoch nich by default die Rechte die Hostsharing braucht, das korrigieren für die Dateien und Ornder jeweils wir mit:

cd ~/helfertool
find static/ -type f -exec chmod 644 {} \;
find static/ -type d -exec chmod 755 {} \;

Leider werden neue hochgeladene Inhalte per default auch mit falschen Permissons angelegt. Das lässt sich fixen indem man folgende Datei ändert. Folgend der geänderte Inhalt:

~/helfertool/src/helfertool/settings.py

# file permissions for newly uploaded files and directories
FILE_UPLOAD_PERMISSIONS = 0o644
FILE_UPLOAD_DIRECTORY_PERMISSIONS = 0o755

um die Python Anwendung mit Passenger auszuliefern sind jetzt noch 2 Schritte nötig:

Eine htaccess Datei im Domain Ordner app-ssl hinterlegen mit dem Inhalt:
SetEnv PYTHONPATH "/home/pacs/opa02/users/helfertool/helfertool/src"
und die wsgi datei in app-ssl hinterlegen:

ln -s ~/helfertool/src/helfertool/wsgi.py ~/doms/example.com/app-ssl/passenger_wsgi.py

Zusätzlich noch im HS Admin den Pfad zum venv hinterlegen

=== Customization ===

Wenn du, wie wir, dieses sehr gute Grün durch eine andere Farbe ersetzen willst kannst du wie folgt vorgehen:

Das zu ersetzende CSS findest du unter <code>~/helfertool/static/compressed/css/</code> mit dem Dateinamen main.<langezahlenfolge>.css diese Datei muss ersetzt werden. Am einfachsten geht das wie folgt:

cd ~/helfertool/static/helfertool/theme
# dort z.b. die Farben ändern
nano _colors.scss
# ggf. noch weitere Änderungen vornehmen
# ...
# compilieren
scss helfertool.scss ../../compressed/main.x.css

In dem o.g. compressed Ordner findet sich dann die neue passende Datei main.x.css, diese einfach über die alte Datei mit der kryptischen Nummer drüber kopieren. Das war es schon :)

Ungetestet: ggf. kann das compilieren auch mit python ~/helfertool/src/manage.py compress ausgelöst werden

Helfertool

2024-05-10T14:20:56Z

Opa00-hostsharing: /* Customization */

== Helfertool.org ==

Helfertool ist eine Software, die es erlaubt, die Freiwilligen oder Mitarbeiter für eine Veranstaltung zu verwalten. Sie können sich online für Jobs registrieren und die Verwaltungsoberfläche erlaubt es, die registrierten Personen zu verwalten. Für jeden Job können verschiedene Schichten mit einer Start- und Endzeit und einer begrenzten Anzahl von Helfern erstellt werden.

Sie ist in Python mit Django geschrieben.

Features lt Website:
* Entscheiden Sie, ob die Registrierung für eine Stelle intern oder öffentlich sichtbar ist.
* Generieren Sie Ausweise zur Identifizierung und Zugangskontrolle.
* Verwaltung von Geschenken für Freiwillige: sie können für jede geleistete Schicht ein Geschenk erhalten, die Organisatoren können vermerken, ob ein Freiwilliger das Geschenk für jede einzelne Schicht erhalten hat.
* Verwaltung von Geschenken für Freiwillige: sie können für jede geleistete Schicht ein Geschenk erhalten, die Organisatoren können vermerken, ob ein Freiwilliger das Geschenk für jede einzelne Schicht erhalten hat.

Mehr Infos auf https://www.helfertool.org

=== Installation ===
Zuerst das git repo clonen. Ggf. Versionsnummer auf die aktuelle Version anpassen.

git clone --single-branch https://github.com/helfertool/helfertool/

Aktuell wird laut src/requirements.txt ein Django in Version 4.2 benötigt.

Aktuell wird dafür

Python 3.8, 3.9, 3.10, 3.11, and 3.12 (as of 4.2. 8)

unterstützt. Auf den debian bookworm Maschinen sollte daher das installierte python3 genügen

python3 --version
Python 3.11.2

Vom Helfertool Docker wird aktuell auch Version 3.11 eingesetzt, nachzusehen in deployment/container/etc/uwsgi.conf

Falls das auf deiner Maschine nicht der Fall ist siehe [[Python]] für die manuelle Installation einer aktuelleren Version.

Wir installieren zuerst die Dependencies, dafür legen wir uns ein venv an um diese nur lokal zu laden.

cd ~
python3 -m venv venv-ht # initalisierung des venv venv-ht
source ~/venv-ht/bin/activate # aktivierung des venv
# installation der dependencies im venv (wichtig! venv-ht muss geladen sein!)
cd helfertool
pip install -r src/requirements.txt -r src/requirements_prod.txt

Für den persönlichen Komfort habe ich folgende Zeilen in der ~/.profile hinterlegt.

source ~/venv-ht/bin/activate

=== Konfiguration ===

Die Config Datei findet sich unter ~/helfertool/src/helfertool.yml

Dort muss insbesondere der Datenbankzugang hinterlegt werden, die Domain bei Allowed Hosts und die E-Mail

ob alles geklappt hat kann mit den folgenden befehlen indirekt getestet werden

python ~/helfertool/src/manage.py migrate
python ~/helfertool/src/manage.py createcachetable
python ~/helfertool/src/manage.py loaddata toolsettings

=== Inbetriebnahme ===

cd ~/helfertool
python src/manage.py collectstatic --noinput

Der neue Erzeugte static ordner wird der htdocs-ssl ordner in der Entsprechenden Domain:

cd ~/doms/example.org/htdocs-ssl
rm .htaccess
ln -s ~/helfertool/static
ln -s ~/helfertool/media

Es sollten dann 2 Links (static und media) in htdocs-ssl liegen die auf die jeweiligen Ordner im git zeigen.

Der statische Assetornder halt leider jedoch nich by default die Rechte die Hostsharing braucht, das korrigieren für die Dateien und Ornder jeweils wir mit:

cd ~/helfertool
find static/ -type f -exec chmod 644 {} \;
find static/ -type d -exec chmod 755 {} \;

Leider werden neue hochgeladene Inhalte per default auch mit falschen Permissons angelegt. Das lässt sich fixen indem man folgende Datei ändert. Folgend der geänderte Inhalt:

~/helfertool/src/helfertool/settings.py

# file permissions for newly uploaded files and directories
FILE_UPLOAD_PERMISSIONS = 0o644
FILE_UPLOAD_DIRECTORY_PERMISSIONS = 0o755

um die Python Anwendung mit Passenger auszuliefern sind jetzt noch 2 Schritte nötig:

Eine htaccess Datei im Domain Ordner app-ssl hinterlegen mit dem Inhalt:
SetEnv PYTHONPATH "/home/pacs/opa02/users/helfertool/helfertool/src"
und die wsgi datei in app-ssl hinterlegen:

ln -s ~/helfertool/src/helfertool/wsgi.py ~/doms/example.com/app-ssl/passenger_wsgi.py

Zusätzlich noch im HS Admin den Pfad zum venv hinterlegen

=== Customization ===

Wenn du, wie wir, dieses sehr gute Grün durch eine andere Farbe ersetzen willst kannst du wie folgt vorgehen:

Das zu ersetzende CSS findest du unter <code>~/helfertool/static/compressed/css/</code> mit dem Dateinamen main.<langezahlenfolge>.css diese Datei muss ersetzt werden. Am einfachsten geht das wie folgt:

cd ~/helfertool/static/helfertool/theme
# dort z.b. die Farben ändern
nano _colors.scss
# ggf. noch weitere Änderungen vornehmen
# ...
# compilieren
scss helfertool.scss ../../compressed/main.x.css

In dem o.g. compressed Ordner findet sich dann die neue passende Datei main.x.css, diese einfach über die alte Datei mit der kryptischen Nummer drüber kopieren. Das war es schon :)

Helfertool

2024-05-10T14:20:25Z

Opa00-hostsharing: /* Customization */

== Helfertool.org ==

Helfertool ist eine Software, die es erlaubt, die Freiwilligen oder Mitarbeiter für eine Veranstaltung zu verwalten. Sie können sich online für Jobs registrieren und die Verwaltungsoberfläche erlaubt es, die registrierten Personen zu verwalten. Für jeden Job können verschiedene Schichten mit einer Start- und Endzeit und einer begrenzten Anzahl von Helfern erstellt werden.

Sie ist in Python mit Django geschrieben.

Features lt Website:
* Entscheiden Sie, ob die Registrierung für eine Stelle intern oder öffentlich sichtbar ist.
* Generieren Sie Ausweise zur Identifizierung und Zugangskontrolle.
* Verwaltung von Geschenken für Freiwillige: sie können für jede geleistete Schicht ein Geschenk erhalten, die Organisatoren können vermerken, ob ein Freiwilliger das Geschenk für jede einzelne Schicht erhalten hat.
* Verwaltung von Geschenken für Freiwillige: sie können für jede geleistete Schicht ein Geschenk erhalten, die Organisatoren können vermerken, ob ein Freiwilliger das Geschenk für jede einzelne Schicht erhalten hat.

Mehr Infos auf https://www.helfertool.org

=== Installation ===
Zuerst das git repo clonen. Ggf. Versionsnummer auf die aktuelle Version anpassen.

git clone --single-branch https://github.com/helfertool/helfertool/

Aktuell wird laut src/requirements.txt ein Django in Version 4.2 benötigt.

Aktuell wird dafür

Python 3.8, 3.9, 3.10, 3.11, and 3.12 (as of 4.2. 8)

unterstützt. Auf den debian bookworm Maschinen sollte daher das installierte python3 genügen

python3 --version
Python 3.11.2

Vom Helfertool Docker wird aktuell auch Version 3.11 eingesetzt, nachzusehen in deployment/container/etc/uwsgi.conf

Falls das auf deiner Maschine nicht der Fall ist siehe [[Python]] für die manuelle Installation einer aktuelleren Version.

Wir installieren zuerst die Dependencies, dafür legen wir uns ein venv an um diese nur lokal zu laden.

cd ~
python3 -m venv venv-ht # initalisierung des venv venv-ht
source ~/venv-ht/bin/activate # aktivierung des venv
# installation der dependencies im venv (wichtig! venv-ht muss geladen sein!)
cd helfertool
pip install -r src/requirements.txt -r src/requirements_prod.txt

Für den persönlichen Komfort habe ich folgende Zeilen in der ~/.profile hinterlegt.

source ~/venv-ht/bin/activate

=== Konfiguration ===

Die Config Datei findet sich unter ~/helfertool/src/helfertool.yml

Dort muss insbesondere der Datenbankzugang hinterlegt werden, die Domain bei Allowed Hosts und die E-Mail

ob alles geklappt hat kann mit den folgenden befehlen indirekt getestet werden

python ~/helfertool/src/manage.py migrate
python ~/helfertool/src/manage.py createcachetable
python ~/helfertool/src/manage.py loaddata toolsettings

=== Inbetriebnahme ===

cd ~/helfertool
python src/manage.py collectstatic --noinput

Der neue Erzeugte static ordner wird der htdocs-ssl ordner in der Entsprechenden Domain:

cd ~/doms/example.org/htdocs-ssl
rm .htaccess
ln -s ~/helfertool/static
ln -s ~/helfertool/media

Es sollten dann 2 Links (static und media) in htdocs-ssl liegen die auf die jeweiligen Ordner im git zeigen.

Der statische Assetornder halt leider jedoch nich by default die Rechte die Hostsharing braucht, das korrigieren für die Dateien und Ornder jeweils wir mit:

cd ~/helfertool
find static/ -type f -exec chmod 644 {} \;
find static/ -type d -exec chmod 755 {} \;

Leider werden neue hochgeladene Inhalte per default auch mit falschen Permissons angelegt. Das lässt sich fixen indem man folgende Datei ändert. Folgend der geänderte Inhalt:

~/helfertool/src/helfertool/settings.py

# file permissions for newly uploaded files and directories
FILE_UPLOAD_PERMISSIONS = 0o644
FILE_UPLOAD_DIRECTORY_PERMISSIONS = 0o755

um die Python Anwendung mit Passenger auszuliefern sind jetzt noch 2 Schritte nötig:

Eine htaccess Datei im Domain Ordner app-ssl hinterlegen mit dem Inhalt:
SetEnv PYTHONPATH "/home/pacs/opa02/users/helfertool/helfertool/src"
und die wsgi datei in app-ssl hinterlegen:

ln -s ~/helfertool/src/helfertool/wsgi.py ~/doms/example.com/app-ssl/passenger_wsgi.py

Zusätzlich noch im HS Admin den Pfad zum venv hinterlegen

=== Customization ===

Wenn du, wie wir, dieses sehr gute Grün durch eine andere Farbe ersetzen willst kannst du wie folgt vorgehen:

Das zu ersetzende CSS findest du unter `~/helfertool/static/compressed/css/` mit dem Dateinamen main.<langezahlenfolge>.css diese Datei muss ersetzt werden. Am einfachsten geht das wie folgt:

cd ~/helfertool/static/helfertool/theme
# dort z.b. die Farben ändern
nano _colors.scss
# ggf. noch weitere Änderungen vornehmen
# ...
# compilieren
scss helfertool.scss ../../compressed/main.x.css

In dem o.g. compressed Ordner findet sich dann die neue passende Datei main.x.css, diese einfach über die alte Datei mit der kryptischen Nummer drüber kopieren. Das war es schon :)

Helfertool

2024-05-10T14:19:55Z

Opa00-hostsharing: farben ändern

== Helfertool.org ==

Helfertool ist eine Software, die es erlaubt, die Freiwilligen oder Mitarbeiter für eine Veranstaltung zu verwalten. Sie können sich online für Jobs registrieren und die Verwaltungsoberfläche erlaubt es, die registrierten Personen zu verwalten. Für jeden Job können verschiedene Schichten mit einer Start- und Endzeit und einer begrenzten Anzahl von Helfern erstellt werden.

Sie ist in Python mit Django geschrieben.

Features lt Website:
* Entscheiden Sie, ob die Registrierung für eine Stelle intern oder öffentlich sichtbar ist.
* Generieren Sie Ausweise zur Identifizierung und Zugangskontrolle.
* Verwaltung von Geschenken für Freiwillige: sie können für jede geleistete Schicht ein Geschenk erhalten, die Organisatoren können vermerken, ob ein Freiwilliger das Geschenk für jede einzelne Schicht erhalten hat.
* Verwaltung von Geschenken für Freiwillige: sie können für jede geleistete Schicht ein Geschenk erhalten, die Organisatoren können vermerken, ob ein Freiwilliger das Geschenk für jede einzelne Schicht erhalten hat.

Mehr Infos auf https://www.helfertool.org

=== Installation ===
Zuerst das git repo clonen. Ggf. Versionsnummer auf die aktuelle Version anpassen.

git clone --single-branch https://github.com/helfertool/helfertool/

Aktuell wird laut src/requirements.txt ein Django in Version 4.2 benötigt.

Aktuell wird dafür

Python 3.8, 3.9, 3.10, 3.11, and 3.12 (as of 4.2. 8)

unterstützt. Auf den debian bookworm Maschinen sollte daher das installierte python3 genügen

python3 --version
Python 3.11.2

Vom Helfertool Docker wird aktuell auch Version 3.11 eingesetzt, nachzusehen in deployment/container/etc/uwsgi.conf

Falls das auf deiner Maschine nicht der Fall ist siehe [[Python]] für die manuelle Installation einer aktuelleren Version.

Wir installieren zuerst die Dependencies, dafür legen wir uns ein venv an um diese nur lokal zu laden.

cd ~
python3 -m venv venv-ht # initalisierung des venv venv-ht
source ~/venv-ht/bin/activate # aktivierung des venv
# installation der dependencies im venv (wichtig! venv-ht muss geladen sein!)
cd helfertool
pip install -r src/requirements.txt -r src/requirements_prod.txt

Für den persönlichen Komfort habe ich folgende Zeilen in der ~/.profile hinterlegt.

source ~/venv-ht/bin/activate

=== Konfiguration ===

Die Config Datei findet sich unter ~/helfertool/src/helfertool.yml

Dort muss insbesondere der Datenbankzugang hinterlegt werden, die Domain bei Allowed Hosts und die E-Mail

ob alles geklappt hat kann mit den folgenden befehlen indirekt getestet werden

python ~/helfertool/src/manage.py migrate
python ~/helfertool/src/manage.py createcachetable
python ~/helfertool/src/manage.py loaddata toolsettings

=== Inbetriebnahme ===

cd ~/helfertool
python src/manage.py collectstatic --noinput

Der neue Erzeugte static ordner wird der htdocs-ssl ordner in der Entsprechenden Domain:

cd ~/doms/example.org/htdocs-ssl
rm .htaccess
ln -s ~/helfertool/static
ln -s ~/helfertool/media

Es sollten dann 2 Links (static und media) in htdocs-ssl liegen die auf die jeweiligen Ordner im git zeigen.

Der statische Assetornder halt leider jedoch nich by default die Rechte die Hostsharing braucht, das korrigieren für die Dateien und Ornder jeweils wir mit:

cd ~/helfertool
find static/ -type f -exec chmod 644 {} \;
find static/ -type d -exec chmod 755 {} \;

Leider werden neue hochgeladene Inhalte per default auch mit falschen Permissons angelegt. Das lässt sich fixen indem man folgende Datei ändert. Folgend der geänderte Inhalt:

~/helfertool/src/helfertool/settings.py

# file permissions for newly uploaded files and directories
FILE_UPLOAD_PERMISSIONS = 0o644
FILE_UPLOAD_DIRECTORY_PERMISSIONS = 0o755

um die Python Anwendung mit Passenger auszuliefern sind jetzt noch 2 Schritte nötig:

Eine htaccess Datei im Domain Ordner app-ssl hinterlegen mit dem Inhalt:
SetEnv PYTHONPATH "/home/pacs/opa02/users/helfertool/helfertool/src"
und die wsgi datei in app-ssl hinterlegen:

ln -s ~/helfertool/src/helfertool/wsgi.py ~/doms/example.com/app-ssl/passenger_wsgi.py

Zusätzlich noch im HS Admin den Pfad zum venv hinterlegen

=== Customization ===

Wenn du, wie wir, dieses sehr gute Grün durch eine andere Farbe ersetzen willst kannst du wie folgt vorgehen:

Das zu ersetzende CSS findest du unter `~/helfertool/static/compressed/css/` mit dem Dateinamen main.<langezahlenfolge>.css diese Datei muss ersetzt werden. Am einfachsten geht das wie folgt:

```
cd ~/helfertool/static/helfertool/theme
# dort z.b. die Farben ändern
nano _colors.scss
# ggf. noch weitere Änderungen vornehmen
# ...
# compilieren
scss helfertool.scss ../../compressed/main.x.css
```
In dem o.g. compressed Ordner findet sich dann die neue passende Datei main.x.css, diese einfach über die alte Datei mit der kryptischen Nummer drüber kopieren. Das war es schon :)

Helfertool

2024-05-10T13:57:31Z

Opa00-hostsharing: /* Inbetriebnahme */

== Helfertool.org ==

Helfertool ist eine Software, die es erlaubt, die Freiwilligen oder Mitarbeiter für eine Veranstaltung zu verwalten. Sie können sich online für Jobs registrieren und die Verwaltungsoberfläche erlaubt es, die registrierten Personen zu verwalten. Für jeden Job können verschiedene Schichten mit einer Start- und Endzeit und einer begrenzten Anzahl von Helfern erstellt werden.

Sie ist in Python mit Django geschrieben.

Features lt Website:
* Entscheiden Sie, ob die Registrierung für eine Stelle intern oder öffentlich sichtbar ist.
* Generieren Sie Ausweise zur Identifizierung und Zugangskontrolle.
* Verwaltung von Geschenken für Freiwillige: sie können für jede geleistete Schicht ein Geschenk erhalten, die Organisatoren können vermerken, ob ein Freiwilliger das Geschenk für jede einzelne Schicht erhalten hat.
* Verwaltung von Geschenken für Freiwillige: sie können für jede geleistete Schicht ein Geschenk erhalten, die Organisatoren können vermerken, ob ein Freiwilliger das Geschenk für jede einzelne Schicht erhalten hat.

Mehr Infos auf https://www.helfertool.org

=== Installation ===
Zuerst das git repo clonen. Ggf. Versionsnummer auf die aktuelle Version anpassen.

git clone --single-branch https://github.com/helfertool/helfertool/

Aktuell wird laut src/requirements.txt ein Django in Version 4.2 benötigt.

Aktuell wird dafür

Python 3.8, 3.9, 3.10, 3.11, and 3.12 (as of 4.2. 8)

unterstützt. Auf den debian bookworm Maschinen sollte daher das installierte python3 genügen

python3 --version
Python 3.11.2

Vom Helfertool Docker wird aktuell auch Version 3.11 eingesetzt, nachzusehen in deployment/container/etc/uwsgi.conf

Falls das auf deiner Maschine nicht der Fall ist siehe [[Python]] für die manuelle Installation einer aktuelleren Version.

Wir installieren zuerst die Dependencies, dafür legen wir uns ein venv an um diese nur lokal zu laden.

cd ~
python3 -m venv venv-ht # initalisierung des venv venv-ht
source ~/venv-ht/bin/activate # aktivierung des venv
# installation der dependencies im venv (wichtig! venv-ht muss geladen sein!)
cd helfertool
pip install -r src/requirements.txt -r src/requirements_prod.txt

Für den persönlichen Komfort habe ich folgende Zeilen in der ~/.profile hinterlegt.

source ~/venv-ht/bin/activate

=== Konfiguration ===

Die Config Datei findet sich unter ~/helfertool/src/helfertool.yml

Dort muss insbesondere der Datenbankzugang hinterlegt werden, die Domain bei Allowed Hosts und die E-Mail

ob alles geklappt hat kann mit den folgenden befehlen indirekt getestet werden

python ~/helfertool/src/manage.py migrate
python ~/helfertool/src/manage.py createcachetable
python ~/helfertool/src/manage.py loaddata toolsettings

=== Inbetriebnahme ===

cd ~/helfertool
python src/manage.py collectstatic --noinput

Der neue Erzeugte static ordner wird der htdocs-ssl ordner in der Entsprechenden Domain:

cd ~/doms/example.org/htdocs-ssl
rm .htaccess
ln -s ~/helfertool/static
ln -s ~/helfertool/media

Es sollten dann 2 Links (static und media) in htdocs-ssl liegen die auf die jeweiligen Ordner im git zeigen.

Der statische Assetornder halt leider jedoch nich by default die Rechte die Hostsharing braucht, das korrigieren für die Dateien und Ornder jeweils wir mit:

cd ~/helfertool
find static/ -type f -exec chmod 644 {} \;
find static/ -type d -exec chmod 755 {} \;

Leider werden neue hochgeladene Inhalte per default auch mit falschen Permissons angelegt. Das lässt sich fixen indem man folgende Datei ändert. Folgend der geänderte Inhalt:

~/helfertool/src/helfertool/settings.py

# file permissions for newly uploaded files and directories
FILE_UPLOAD_PERMISSIONS = 0o644
FILE_UPLOAD_DIRECTORY_PERMISSIONS = 0o755

um die Python Anwendung mit Passenger auszuliefern sind jetzt noch 2 Schritte nötig:

Eine htaccess Datei im Domain Ordner app-ssl hinterlegen mit dem Inhalt:
SetEnv PYTHONPATH "/home/pacs/opa02/users/helfertool/helfertool/src"
und die wsgi datei in app-ssl hinterlegen:

ln -s ~/helfertool/src/helfertool/wsgi.py ~/doms/example.com/app-ssl/passenger_wsgi.py

Zusätzlich noch im HS Admin den Pfad zum venv hinterlegen

Helfertool

2024-05-10T13:55:14Z

Opa00-hostsharing: upload settings

== Helfertool.org ==

Helfertool ist eine Software, die es erlaubt, die Freiwilligen oder Mitarbeiter für eine Veranstaltung zu verwalten. Sie können sich online für Jobs registrieren und die Verwaltungsoberfläche erlaubt es, die registrierten Personen zu verwalten. Für jeden Job können verschiedene Schichten mit einer Start- und Endzeit und einer begrenzten Anzahl von Helfern erstellt werden.

Sie ist in Python mit Django geschrieben.

Features lt Website:
* Entscheiden Sie, ob die Registrierung für eine Stelle intern oder öffentlich sichtbar ist.
* Generieren Sie Ausweise zur Identifizierung und Zugangskontrolle.
* Verwaltung von Geschenken für Freiwillige: sie können für jede geleistete Schicht ein Geschenk erhalten, die Organisatoren können vermerken, ob ein Freiwilliger das Geschenk für jede einzelne Schicht erhalten hat.
* Verwaltung von Geschenken für Freiwillige: sie können für jede geleistete Schicht ein Geschenk erhalten, die Organisatoren können vermerken, ob ein Freiwilliger das Geschenk für jede einzelne Schicht erhalten hat.

Mehr Infos auf https://www.helfertool.org

=== Installation ===
Zuerst das git repo clonen. Ggf. Versionsnummer auf die aktuelle Version anpassen.

git clone --single-branch https://github.com/helfertool/helfertool/

Aktuell wird laut src/requirements.txt ein Django in Version 4.2 benötigt.

Aktuell wird dafür

Python 3.8, 3.9, 3.10, 3.11, and 3.12 (as of 4.2. 8)

unterstützt. Auf den debian bookworm Maschinen sollte daher das installierte python3 genügen

python3 --version
Python 3.11.2

Vom Helfertool Docker wird aktuell auch Version 3.11 eingesetzt, nachzusehen in deployment/container/etc/uwsgi.conf

Falls das auf deiner Maschine nicht der Fall ist siehe [[Python]] für die manuelle Installation einer aktuelleren Version.

Wir installieren zuerst die Dependencies, dafür legen wir uns ein venv an um diese nur lokal zu laden.

cd ~
python3 -m venv venv-ht # initalisierung des venv venv-ht
source ~/venv-ht/bin/activate # aktivierung des venv
# installation der dependencies im venv (wichtig! venv-ht muss geladen sein!)
cd helfertool
pip install -r src/requirements.txt -r src/requirements_prod.txt

Für den persönlichen Komfort habe ich folgende Zeilen in der ~/.profile hinterlegt.

source ~/venv-ht/bin/activate

=== Konfiguration ===

Die Config Datei findet sich unter ~/helfertool/src/helfertool.yml

Dort muss insbesondere der Datenbankzugang hinterlegt werden, die Domain bei Allowed Hosts und die E-Mail

ob alles geklappt hat kann mit den folgenden befehlen indirekt getestet werden

python ~/helfertool/src/manage.py migrate
python ~/helfertool/src/manage.py createcachetable
python ~/helfertool/src/manage.py loaddata toolsettings

=== Inbetriebnahme ===

cd ~/helfertool
venv/bin/python src/manage.py collectstatic --noinput

Der neue Erzeugte static ordner wird der htdocs-ssl ordner in der Entsprechenden Domain:

cd ~/doms/example.org/htdocs-ssl
rm .htaccess
ln -s ~/helfertool/static
ln -s ~/helfertool/media

Es sollten dann 2 Links (static und media) in htdocs-ssl liegen die auf die jeweiligen Ordner im git zeigen.

Der statische Assetornder halt leider jedoch nich by default die Rechte die Hostsharing braucht, das korrigieren für die Dateien und Ornder jeweils wir mit:

cd ~/helfertool
find static/ -type f -exec chmod 644 {} \;
find static/ -type d -exec chmod 755 {} \;

Leider werden neue hochgeladene Inhalte per default auch mit falschen Permissons angelegt. Das lässt sich fixen indem man folgende Datei ändert. Folgend der geänderte Inhalt:

~/helfertool/src/helfertool/settings.py

# file permissions for newly uploaded files and directories
FILE_UPLOAD_PERMISSIONS = 0o644
FILE_UPLOAD_DIRECTORY_PERMISSIONS = 0o755

um die Python Anwendung mit Passenger auszuliefern sind jetzt noch 2 Schritte nötig:

Eine htaccess Datei im Domain Ordner app-ssl hinterlegen mit dem Inhalt:
SetEnv PYTHONPATH "/home/pacs/opa02/users/helfertool/helfertool/src"
und die wsgi datei in app-ssl hinterlegen:

ln -s ~/helfertool/src/helfertool/wsgi.py ~/doms/example.com/app-ssl/passenger_wsgi.py

Zusätzlich noch im HS Admin den Pfad zum venv hinterlegen

Helfertool

2024-01-30T13:28:47Z

Opa00-hostsharing:

== Helfertool.org ==

Helfertool ist eine Software, die es erlaubt, die Freiwilligen oder Mitarbeiter für eine Veranstaltung zu verwalten. Sie können sich online für Jobs registrieren und die Verwaltungsoberfläche erlaubt es, die registrierten Personen zu verwalten. Für jeden Job können verschiedene Schichten mit einer Start- und Endzeit und einer begrenzten Anzahl von Helfern erstellt werden.

Sie ist in Python mit Django geschrieben.

Features lt Website:
* Entscheiden Sie, ob die Registrierung für eine Stelle intern oder öffentlich sichtbar ist.
* Generieren Sie Ausweise zur Identifizierung und Zugangskontrolle.
* Verwaltung von Geschenken für Freiwillige: sie können für jede geleistete Schicht ein Geschenk erhalten, die Organisatoren können vermerken, ob ein Freiwilliger das Geschenk für jede einzelne Schicht erhalten hat.
* Verwaltung von Geschenken für Freiwillige: sie können für jede geleistete Schicht ein Geschenk erhalten, die Organisatoren können vermerken, ob ein Freiwilliger das Geschenk für jede einzelne Schicht erhalten hat.

Mehr Infos auf https://www.helfertool.org

=== Installation ===
Zuerst das git repo clonen. Ggf. Versionsnummer auf die aktuelle Version anpassen.

git clone --single-branch https://github.com/helfertool/helfertool/

Aktuell wird laut src/requirements.txt ein Django in Version 4.2 benötigt.

Aktuell wird dafür

Python 3.8, 3.9, 3.10, 3.11, and 3.12 (as of 4.2. 8)

unterstützt. Auf den debian bookworm Maschinen sollte daher das installierte python3 genügen

python3 --version
Python 3.11.2

Vom Helfertool Docker wird aktuell auch Version 3.11 eingesetzt, nachzusehen in deployment/container/etc/uwsgi.conf

Falls das auf deiner Maschine nicht der Fall ist siehe [[Python]] für die manuelle Installation einer aktuelleren Version.

Wir installieren zuerst die Dependencies, dafür legen wir uns ein venv an um diese nur lokal zu laden.

cd ~
python3 -m venv venv-ht # initalisierung des venv venv-ht
source ~/venv-ht/bin/activate # aktivierung des venv
# installation der dependencies im venv (wichtig! venv-ht muss geladen sein!)
cd helfertool
pip install -r src/requirements.txt -r src/requirements_prod.txt

Für den persönlichen Komfort habe ich folgende Zeilen in der ~/.profile hinterlegt.

source ~/venv-ht/bin/activate

=== Konfiguration ===

Die Config Datei findet sich unter ~/helfertool/src/helfertool.yml

Dort muss insbesondere der Datenbankzugang hinterlegt werden, die Domain bei Allowed Hosts und die E-Mail

ob alles geklappt hat kann mit den folgenden befehlen indirekt getestet werden

python ~/helfertool/src/manage.py migrate
python ~/helfertool/src/manage.py createcachetable
python ~/helfertool/src/manage.py loaddata toolsettings

=== Inbetriebnahme ===

cd ~/helfertool
venv/bin/python src/manage.py collectstatic --noinput

Der neue Erzeugte static ordner wird der htdocs-ssl ordner in der Entsprechenden Domain:

cd ~/doms/example.org/htdocs-ssl
rm .htaccess
ln -s ~/helfertool/static
ln -s ~/helfertool/media

Es sollten dann 2 Links (static und media) in htdocs-ssl liegen die auf die jeweiligen Ordner im git zeigen.

Der statische Assetornder halt leider jedoch nich by default die Rechte die Hostsharing braucht, das korrigieren für die Dateien und Ornder jeweils wir mit:

cd ~/helfertool
find static/ -type f -exec chmod 644 {} \;
find static/ -type d -exec chmod 755 {} \;

um die Python Anwendung mit Passenger auszuliefern sind jetzt noch 2 Schritte nötig:

Eine htaccess Datei im Domain Ordner app-ssl hinterlegen mit dem Inhalt:
SetEnv PYTHONPATH "/home/pacs/opa02/users/helfertool/helfertool/src"
und die wsgi datei in app-ssl hinterlegen:

ln -s ~/helfertool/src/helfertool/wsgi.py ~/doms/example.com/app-ssl/passenger_wsgi.py

Zusätzlich noch im HS Admin den Pfad zum venv hinterlegen

Helfertool

2024-01-30T12:31:24Z

Opa00-hostsharing: /* Inbetriebnahme */

== Helfertool.org ==

Helfertool ist eine Software, die es erlaubt, die Freiwilligen oder Mitarbeiter für eine Veranstaltung zu verwalten. Sie können sich online für Jobs registrieren und die Verwaltungsoberfläche erlaubt es, die registrierten Personen zu verwalten. Für jeden Job können verschiedene Schichten mit einer Start- und Endzeit und einer begrenzten Anzahl von Helfern erstellt werden.

Sie ist in Python mit Django geschrieben.

Features lt Website:
* Entscheiden Sie, ob die Registrierung für eine Stelle intern oder öffentlich sichtbar ist.
* Generieren Sie Ausweise zur Identifizierung und Zugangskontrolle.
* Verwaltung von Geschenken für Freiwillige: sie können für jede geleistete Schicht ein Geschenk erhalten, die Organisatoren können vermerken, ob ein Freiwilliger das Geschenk für jede einzelne Schicht erhalten hat.
* Verwaltung von Geschenken für Freiwillige: sie können für jede geleistete Schicht ein Geschenk erhalten, die Organisatoren können vermerken, ob ein Freiwilliger das Geschenk für jede einzelne Schicht erhalten hat.

Mehr Infos auf https://www.helfertool.org

=== Installation ===
Zuerst das git repo clonen. Ggf. Versionsnummer auf die aktuelle Version anpassen.

git clone --single-branch https://github.com/helfertool/helfertool/

Aktuell wird laut src/requirements.txt ein Django in Version 4.2 benötigt.

Aktuell wird dafür

Python 3.8, 3.9, 3.10, 3.11, and 3.12 (as of 4.2. 8)

unterstützt. Auf den debian bookworm Maschinen sollte daher das installierte python3 genügen

python3 --version
Python 3.11.2

Vom Helfertool Docker wird aktuell auch Version 3.11 eingesetzt, nachzusehen in deployment/container/etc/uwsgi.conf

Falls das auf deiner Maschine nicht der Fall ist siehe [[Python]] für die manuelle Installation einer aktuelleren Version.

Wir installieren zuerst die Dependencies, dafür legen wir uns ein venv an um diese nur lokal zu laden.

cd ~
python3 -m venv venv-ht # initalisierung des venv venv-ht
source ~/venv-ht/bin/activate # aktivierung des venv
# installation der dependencies im venv (wichtig! venv-ht muss geladen sein!)
cd helfertool
pip install -r src/requirements.txt -r src/requirements_prod.txt

Für den persönlichen Komfort habe ich folgende Zeilen in der ~/.profile hinterlegt.

source ~/venv-ht/bin/activate

=== Konfiguration ===

Die Config Datei findet sich unter ~/helfertool/src/helfertool.yml

Dort muss insbesondere der Datenbankzugang hinterlegt werden, die Domain bei Allowed Hosts und die E-Mail

ob alles geklappt hat kann mit den folgenden befehlen indirekt getestet werden

python ~/helfertool/src/manage.py migrate
python ~/helfertool/src/manage.py loaddata toolsettings

=== Inbetriebnahme ===

cd ~/helfertool
venv/bin/python src/manage.py collectstatic --noinput

Der neue Erzeugte static ordner wird der htdocs-ssl ordner in der Entsprechenden Domain:

cd ~/doms/example.org/htdocs-ssl
rm .htaccess
ln -s ~/helfertool/static
ln -s ~/helfertool/media

Es sollten dann 2 Links (static und media) in htdocs-ssl liegen die auf die jeweiligen Ordner im git zeigen.

Der statische Assetornder halt leider jedoch nich by default die Rechte die Hostsharing braucht, das korrigieren für die Dateien und Ornder jeweils wir mit:

cd ~/helfertool
find static/ -type f -exec chmod 644 {} \;
find static/ -type d -exec chmod 755 {} \;

um die Python Anwendung mit Passenger auszuliefern sind jetzt noch 2 Schritte nötig:

Eine htaccess Datei im Domain Ordner app-ssl hinterlegen mit dem Inhalt:
SetEnv PYTHONPATH "/home/pacs/opa02/users/helfertool/helfertool/src"
und die wsgi datei in app-ssl hinterlegen:

ln -s ~/helfertool/src/helfertool/wsgi.py ~/doms/example.com/app-ssl/passenger_wsgi.py

Zusätzlich noch im HS Admin den Pfad zum venv hinterlegen

Helfertool

2024-01-30T12:19:26Z

Opa00-hostsharing:

== Helfertool.org ==

Helfertool ist eine Software, die es erlaubt, die Freiwilligen oder Mitarbeiter für eine Veranstaltung zu verwalten. Sie können sich online für Jobs registrieren und die Verwaltungsoberfläche erlaubt es, die registrierten Personen zu verwalten. Für jeden Job können verschiedene Schichten mit einer Start- und Endzeit und einer begrenzten Anzahl von Helfern erstellt werden.

Sie ist in Python mit Django geschrieben.

Features lt Website:
* Entscheiden Sie, ob die Registrierung für eine Stelle intern oder öffentlich sichtbar ist.
* Generieren Sie Ausweise zur Identifizierung und Zugangskontrolle.
* Verwaltung von Geschenken für Freiwillige: sie können für jede geleistete Schicht ein Geschenk erhalten, die Organisatoren können vermerken, ob ein Freiwilliger das Geschenk für jede einzelne Schicht erhalten hat.
* Verwaltung von Geschenken für Freiwillige: sie können für jede geleistete Schicht ein Geschenk erhalten, die Organisatoren können vermerken, ob ein Freiwilliger das Geschenk für jede einzelne Schicht erhalten hat.

Mehr Infos auf https://www.helfertool.org

=== Installation ===
Zuerst das git repo clonen. Ggf. Versionsnummer auf die aktuelle Version anpassen.

git clone --single-branch https://github.com/helfertool/helfertool/

Aktuell wird laut src/requirements.txt ein Django in Version 4.2 benötigt.

Aktuell wird dafür

Python 3.8, 3.9, 3.10, 3.11, and 3.12 (as of 4.2. 8)

unterstützt. Auf den debian bookworm Maschinen sollte daher das installierte python3 genügen

python3 --version
Python 3.11.2

Vom Helfertool Docker wird aktuell auch Version 3.11 eingesetzt, nachzusehen in deployment/container/etc/uwsgi.conf

Falls das auf deiner Maschine nicht der Fall ist siehe [[Python]] für die manuelle Installation einer aktuelleren Version.

Wir installieren zuerst die Dependencies, dafür legen wir uns ein venv an um diese nur lokal zu laden.

cd ~
python3 -m venv venv-ht # initalisierung des venv venv-ht
source ~/venv-ht/bin/activate # aktivierung des venv
# installation der dependencies im venv (wichtig! venv-ht muss geladen sein!)
cd helfertool
pip install -r src/requirements.txt -r src/requirements_prod.txt

Für den persönlichen Komfort habe ich folgende Zeilen in der ~/.profile hinterlegt.

source ~/venv-ht/bin/activate

=== Konfiguration ===

Die Config Datei findet sich unter ~/helfertool/src/helfertool.yml

Dort muss insbesondere der Datenbankzugang hinterlegt werden, die Domain bei Allowed Hosts und die E-Mail

ob alles geklappt hat kann mit den folgenden befehlen indirekt getestet werden

python ~/helfertool/src/manage.py migrate
python ~/helfertool/src/manage.py loaddata toolsettings

=== Inbetriebnahme ===

cd ~/helfertool
venv/bin/python src/manage.py collectstatic --noinput

Der neue Erzeugte static ordner wird der htdocs-ssl ordner in der Entsprechenden Domain:

cd ~/doms/example.org/
rm -r htdocs-ssl
ln -s ~/helfertool/static htdocs-ssl

Der statische Assetornder halt leider jedoch nich by default die Rechte die Hostsharing braucht, das korrigieren für die Dateien und Ornder jeweils wir mit:

find static/ -type f -exec chmod 644 {} \;
find static/ -type d -exec chmod 755 {} \;

um die Python Anwendung mit Passenger auszuliefern sind jetzt noch 2 Schritte nötig:

Eine htaccess Datei im Domain Ordner app-ssl hinterlegen mit dem Inhalt:
SetEnv PYTHONPATH "/home/pacs/opa02/users/helfertool/helfertool/src"
und die wsgi datei in app-ssl hinterlegen:

ln -s ~/helfertool/src/helfertool/wsgi.py ~/doms/example.com/app-ssl/passenger_wsgi.py

Zusätzlich noch im HS Admin den Pfad zum venv hinterlegen

Helfertool

2024-01-30T10:19:51Z

Opa00-hostsharing: /* Inbetriebnahme */

Helfertool

2024-01-27T14:11:20Z

Opa00-hostsharing: /* Inbetriebnahme */

Helfertool

2024-01-27T14:08:32Z

Opa00-hostsharing: /* Inbetriebnahme */

Helfertool

2024-01-27T13:06:54Z

Opa00-hostsharing: /* Helfertool.org */

Helfertool

2024-01-27T13:01:45Z

Opa00-hostsharing: /* Konfiguration */

Helfertool

2024-01-27T11:43:13Z

Opa00-hostsharing: /* Installation */

Helfertool

2024-01-27T11:40:05Z

Opa00-hostsharing:

Helfertool

2024-01-27T11:35:50Z

Opa00-hostsharing: /* Installation */

Helfertool

2024-01-27T10:31:19Z

Opa00-hostsharing: init

Wordpress

2024-01-09T16:09:26Z

Opa00-hostsharing: /* Bestehendes Wordpress auf neuen User / Server umziehen / Uploads auf Storage auslagern */

= Wordpress in 5 Minuten =

Installiert wird Wordpress hier unter der Domain https://blog.example.org.

== 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 ''blog.example.org''
* MySQL-User
* MySQL Datenbank

xyz00@hsadmin> user.add({set:{name:'xyz00-blog',password:'geheim',shell:'/bin/bash',comment:'Wordpress Blog'}})
xyz00@hsadmin> domain.add({set:{name:'blog.example.org',user:'xyz00-blog'}})
xyz00@hsadmin> mysqluser.add({set:{name:'xyz00_wpuser',password:'geheim'}})
xyz00@hsadmin> mysqldb.add({set:{name:'xyz00_wpdb',owner:'xyz00_wpuser'}})

== Wordpress installieren ==

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

ssh -l xyz00-blog xyz00.hostsharing.net

''htdocs-ssl'' Verzeichnis vorbereiten

cd doms/blog.example.org
rm -rf subs/www subs-ssl/www
cd htdocs-ssl
rm .htaccess

Wordpress downloaden & entpacken z.b. im htdocs-ssl Verzeichnis

wget -O - https://wordpress.org/latest.tar.gz |tar -xz --strip 1

== Wordpress konfigurieren ==

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

== Uraltes Wordpress aktualisieren ==

Manche Wordpress Installationen sind so alt, dass wp-login nicht mehr funktioniert.

Mit wp-cli kann Wordpress auf die aktuelle Version aktualisiert werden:

mkdir ~/bin
cd ~/bin
wget https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod a+x wp-cli.phar
cd ~/wordpress # oder ~/doms/meinedomain.de/subs-ssl/www/ oder wo sonst Wordpress installiert ist
~/bin/wp-cli.phar core update

== Bestehendes Wordpress auf neue Domain umziehen ==
Meistens muss nichts weiter geändert werden als die Home und die SITE_URL Option.

Einfach zu ändern geht das indem man sich via phpmyadmin.hostsharing.net in den Datenbank User des Wordpress einloggt und sich die Tabelle wp_options ansieht. Dort müssen die Zeilen mit `siteurl` und `home` an die neuen URLs angepasst werden.

Alternativ kann man das auch über das wp-config.php machen. Meistens gibt es die beiden Einträge noch nicht, einfach an die passende Stelle für die Custom Config neu eintragen:

define('WP_HOME','https://www.new-domain.de/');
define('WP_SITEURL','https://www.new-domain.de/');

Generell lohnt es sich die wp_options Tabelle mal noch auf alte Domain Einträge zu untersuchen und ggf zu ersetzen.
Das geht z.B. so:

SELECT * FROM wp_options WHERE option_value LIKE "%https://old-domain.de%"

== Bestehendes Wordpress auf neuen User / Server umziehen / Uploads auf Storage auslagern ==

Meistens muss dafür keine weitere Änderung vorgenommen werden. Manchmal haben vorherige Anbieter einen alternativen Upload Pfad gesetzt. Das zeigt sich dadurch das man angeblich keine Schreibberechtigungen hätte beim Hochladen von z.B. Bildern.

Eine Möglichkeit was dort kaputt sein könnte ist, das die Option `upload_path` noch auf einen alten Pfad vom alten Anbieter gesetzt wurde. Diese Option ist auch zu gebrauchen wenn der häufiger doch mal recht schnell wachsende Uploads Ordner auf den Storage und nicht auf die SSD ausgelagert werden soll.

In der wp_options DB-Tabelle muss entsprechend die Variable `upload_path` angepasst werden. z.B. für den User xyz00-wordpress zu /home/storage/xyz00/users/wordpress/uploads

Generell lohnt es sich die wp_options Tabelle noch mal auf den Alten Pfad zu untersuchen und ggf. anzupassen, das geht z.B. so:

SELECT * FROM wp_options WHERE option_value LIKE "%/old/path/%"

== Links ==

*[https://wordpress.org/ Offizielle Webseite von Wordpress]
*[https://github.com/tpokorra/Hostsharing-Ansible-Wordpress Ansible Playbook für Hostsharing]

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:Software]]
[[Kategorie:Blog]]
[[Kategorie:CMS]]

Wordpress

2024-01-09T16:08:04Z

Opa00-hostsharing:

= Wordpress in 5 Minuten =

Installiert wird Wordpress hier unter der Domain https://blog.example.org.

== 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 ''blog.example.org''
* MySQL-User
* MySQL Datenbank

xyz00@hsadmin> user.add({set:{name:'xyz00-blog',password:'geheim',shell:'/bin/bash',comment:'Wordpress Blog'}})
xyz00@hsadmin> domain.add({set:{name:'blog.example.org',user:'xyz00-blog'}})
xyz00@hsadmin> mysqluser.add({set:{name:'xyz00_wpuser',password:'geheim'}})
xyz00@hsadmin> mysqldb.add({set:{name:'xyz00_wpdb',owner:'xyz00_wpuser'}})

== Wordpress installieren ==

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

ssh -l xyz00-blog xyz00.hostsharing.net

''htdocs-ssl'' Verzeichnis vorbereiten

cd doms/blog.example.org
rm -rf subs/www subs-ssl/www
cd htdocs-ssl
rm .htaccess

Wordpress downloaden & entpacken z.b. im htdocs-ssl Verzeichnis

wget -O - https://wordpress.org/latest.tar.gz |tar -xz --strip 1

== Wordpress konfigurieren ==

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

== Uraltes Wordpress aktualisieren ==

Manche Wordpress Installationen sind so alt, dass wp-login nicht mehr funktioniert.

Mit wp-cli kann Wordpress auf die aktuelle Version aktualisiert werden:

mkdir ~/bin
cd ~/bin
wget https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod a+x wp-cli.phar
cd ~/wordpress # oder ~/doms/meinedomain.de/subs-ssl/www/ oder wo sonst Wordpress installiert ist
~/bin/wp-cli.phar core update

== Bestehendes Wordpress auf neue Domain umziehen ==
Meistens muss nichts weiter geändert werden als die Home und die SITE_URL Option.

Einfach zu ändern geht das indem man sich via phpmyadmin.hostsharing.net in den Datenbank User des Wordpress einloggt und sich die Tabelle wp_options ansieht. Dort müssen die Zeilen mit `siteurl` und `home` an die neuen URLs angepasst werden.

Alternativ kann man das auch über das wp-config.php machen. Meistens gibt es die beiden Einträge noch nicht, einfach an die passende Stelle für die Custom Config neu eintragen:

define('WP_HOME','https://www.new-domain.de/');
define('WP_SITEURL','https://www.new-domain.de/');

Generell lohnt es sich die wp_options Tabelle mal noch auf alte Domain Einträge zu untersuchen und ggf zu ersetzen.
Das geht z.B. so:

SELECT * FROM wp_options WHERE option_value LIKE "%https://old-domain.de%"

== Bestehendes Wordpress auf neuen User / Server umziehen / Uploads auf Storage auslagern ==

Meistens muss dafür keine weitere Änderung vorgenommen werden. Manchmal haben vorherige Anbieter einen alternativen Upload Pfad gesetzt. Das zeigt sich dadurch das man angeblich keine Schreibberechtigungen hätte beim Hochladen von z.B. Bildern.

Eine Möglichkeit was dort kaputt sein könnte ist, das die Option `upload_path` noch auf einen alten Pfad vom alten Anbieter gesetzt wurde. Diese Option ist auch zu gebrauchen wenn der häufiger doch mal recht schnell wachsende Uploads Ordner auf den Storage und nicht auf die SSD ausgelagert werden soll.

In der wp_options DB-Tabelle muss entsprechend die Variable `upload_path` angepasst werden. z.B. für den User xyz00-wordpress zu /home/storage/xyz00/users/wordpress/uploads

== Links ==

*[https://wordpress.org/ Offizielle Webseite von Wordpress]
*[https://github.com/tpokorra/Hostsharing-Ansible-Wordpress Ansible Playbook für Hostsharing]

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:Software]]
[[Kategorie:Blog]]
[[Kategorie:CMS]]

Wordpress

2024-01-09T16:07:42Z

Opa00-hostsharing: /* Bestehendes Wordpress auf neue Domain umziehen */

= Wordpress in 5 Minuten =

Installiert wird Wordpress hier unter der Domain https://blog.example.org.

== 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 ''blog.example.org''
* MySQL-User
* MySQL Datenbank

xyz00@hsadmin> user.add({set:{name:'xyz00-blog',password:'geheim',shell:'/bin/bash',comment:'Wordpress Blog'}})
xyz00@hsadmin> domain.add({set:{name:'blog.example.org',user:'xyz00-blog'}})
xyz00@hsadmin> mysqluser.add({set:{name:'xyz00_wpuser',password:'geheim'}})
xyz00@hsadmin> mysqldb.add({set:{name:'xyz00_wpdb',owner:'xyz00_wpuser'}})

== Wordpress installieren ==

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

ssh -l xyz00-blog xyz00.hostsharing.net

''htdocs-ssl'' Verzeichnis vorbereiten

cd doms/blog.example.org
rm -rf subs/www subs-ssl/www
cd htdocs-ssl
rm .htaccess

Wordpress downloaden & entpacken z.b. im htdocs-ssl Verzeichnis

wget -O - https://wordpress.org/latest.tar.gz |tar -xz --strip 1

== Wordpress konfigurieren ==

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

== Uraltes Wordpress aktualisieren ==

Manche Wordpress Installationen sind so alt, dass wp-login nicht mehr funktioniert.

Mit wp-cli kann Wordpress auf die aktuelle Version aktualisiert werden:

mkdir ~/bin
cd ~/bin
wget https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod a+x wp-cli.phar
cd ~/wordpress # oder ~/doms/meinedomain.de/subs-ssl/www/ oder wo sonst Wordpress installiert ist
~/bin/wp-cli.phar core update

== Bestehendes Wordpress auf neue Domain umziehen ==
Meistens muss nichts weiter geändert werden als die Home und die SITE_URL Option.

Einfach zu ändern geht das indem man sich via phpmyadmin.hostsharing.net in den Datenbank User des Wordpress einloggt und sich die Tabelle wp_options ansieht. Dort müssen die Zeilen mit `siteurl` und `home` an die neuen URLs angepasst werden.

Alternativ kann man das auch über das wp-config.php machen. Meistens gibt es die beiden Einträge noch nicht, einfach an die passende Stelle für die Custom Config neu eintragen:

define('WP_HOME','https://www.new-domain.de/');
define('WP_SITEURL','https://www.new-domain.de/');

Generell lohnt es sich die wp_options Tabelle mal noch auf alte Domain Einträge zu untersuchen und ggf zu ersetzen.
Das geht z.B. so: SELECT * FROM wp_options WHERE option_value LIKE "%https://old-domain.de%"

== Bestehendes Wordpress auf neuen User / Server umziehen / Uploads auf Storage auslagern ==

Meistens muss dafür keine weitere Änderung vorgenommen werden. Manchmal haben vorherige Anbieter einen alternativen Upload Pfad gesetzt. Das zeigt sich dadurch das man angeblich keine Schreibberechtigungen hätte beim Hochladen von z.B. Bildern.

Eine Möglichkeit was dort kaputt sein könnte ist, das die Option `upload_path` noch auf einen alten Pfad vom alten Anbieter gesetzt wurde. Diese Option ist auch zu gebrauchen wenn der häufiger doch mal recht schnell wachsende Uploads Ordner auf den Storage und nicht auf die SSD ausgelagert werden soll.

In der wp_options DB-Tabelle muss entsprechend die Variable `upload_path` angepasst werden. z.B. für den User xyz00-wordpress zu /home/storage/xyz00/users/wordpress/uploads

== Links ==

*[https://wordpress.org/ Offizielle Webseite von Wordpress]
*[https://github.com/tpokorra/Hostsharing-Ansible-Wordpress Ansible Playbook für Hostsharing]

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:Software]]
[[Kategorie:Blog]]
[[Kategorie:CMS]]

Wordpress

2024-01-09T16:06:08Z

Opa00-hostsharing:

= Wordpress in 5 Minuten =

Installiert wird Wordpress hier unter der Domain https://blog.example.org.

== 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 ''blog.example.org''
* MySQL-User
* MySQL Datenbank

xyz00@hsadmin> user.add({set:{name:'xyz00-blog',password:'geheim',shell:'/bin/bash',comment:'Wordpress Blog'}})
xyz00@hsadmin> domain.add({set:{name:'blog.example.org',user:'xyz00-blog'}})
xyz00@hsadmin> mysqluser.add({set:{name:'xyz00_wpuser',password:'geheim'}})
xyz00@hsadmin> mysqldb.add({set:{name:'xyz00_wpdb',owner:'xyz00_wpuser'}})

== Wordpress installieren ==

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

ssh -l xyz00-blog xyz00.hostsharing.net

''htdocs-ssl'' Verzeichnis vorbereiten

cd doms/blog.example.org
rm -rf subs/www subs-ssl/www
cd htdocs-ssl
rm .htaccess

Wordpress downloaden & entpacken z.b. im htdocs-ssl Verzeichnis

wget -O - https://wordpress.org/latest.tar.gz |tar -xz --strip 1

== Wordpress konfigurieren ==

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

== Uraltes Wordpress aktualisieren ==

Manche Wordpress Installationen sind so alt, dass wp-login nicht mehr funktioniert.

Mit wp-cli kann Wordpress auf die aktuelle Version aktualisiert werden:

mkdir ~/bin
cd ~/bin
wget https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod a+x wp-cli.phar
cd ~/wordpress # oder ~/doms/meinedomain.de/subs-ssl/www/ oder wo sonst Wordpress installiert ist
~/bin/wp-cli.phar core update

== Bestehendes Wordpress auf neue Domain umziehen ==
Meistens muss nichts weiter geändert werden als die Home und die SITE_URL Option.

Einfach zu ändern geht das indem man sich via phpmyadmin.hostsharing.net in den Datenbank User des Wordpress einloggt und sich die Tabelle wp_options ansieht. Dort müssen die Zeilen mit `siteurl` und `home` an die neuen URLs angepasst werden.

Alternativ kann man das auch über das wp-config.php machen. Meistens gibt es die beiden Einträge noch nicht, einfach an die passende Stelle für die Custom Config neu eintragen:

define('WP_HOME','https://www.new-domain.de/');
define('WP_SITEURL','https://www.new-domain.de/');

== Bestehendes Wordpress auf neuen User / Server umziehen / Uploads auf Storage auslagern ==

Meistens muss dafür keine weitere Änderung vorgenommen werden. Manchmal haben vorherige Anbieter einen alternativen Upload Pfad gesetzt. Das zeigt sich dadurch das man angeblich keine Schreibberechtigungen hätte beim Hochladen von z.B. Bildern.

Eine Möglichkeit was dort kaputt sein könnte ist, das die Option `upload_path` noch auf einen alten Pfad vom alten Anbieter gesetzt wurde. Diese Option ist auch zu gebrauchen wenn der häufiger doch mal recht schnell wachsende Uploads Ordner auf den Storage und nicht auf die SSD ausgelagert werden soll.

In der wp_options DB-Tabelle muss entsprechend die Variable `upload_path` angepasst werden. z.B. für den User xyz00-wordpress zu /home/storage/xyz00/users/wordpress/uploads

== Links ==

*[https://wordpress.org/ Offizielle Webseite von Wordpress]
*[https://github.com/tpokorra/Hostsharing-Ansible-Wordpress Ansible Playbook für Hostsharing]

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:Software]]
[[Kategorie:Blog]]
[[Kategorie:CMS]]

Wordpress

2024-01-09T15:58:55Z

Opa00-hostsharing: Anleitung zum Domainumzug