The university hosts a matrix server which can be used with the university internal credentials. This page gives a quick introduction on how to setup 'element', the reference implementation of the client. You can of course use other implementations (there are plenty) and similar steps probably apply to those as well. However, you are on your own! Also, element is by far the most feature complete as of now. You might want to consider that. For a list of other clients and general information about matrix check [https://matrix.org/ matrix.org].

There is also some information on the [https://www.rrze.fau.de/serverdienste/matrix/ RRZE page].

The rest of the page describes the setup on our cluster, it should be similar on your laptop (if you choose to install it there too) but better consider also reading up instructions for your system.

== First start of element ==

Element can be started like any other program, from the command line the simplest is to type <code>element-desktop</code>.

On first start you might be greeted with an error message about ''not finding save storage for secrets'' if so, this is already your first encounter with what makes the matrix system slightly more difficult than your off-the-shelf chat software. Here is the TLDR: Matrix is a distributed protocol, so no central authority. Therefore it is vital that every user can authenticate themself to a server and, more importantly, authenticate any other user. This is done by encryption keys (if you encrypt your emails, the very same mechanism is used).

To store keys a keyring is used (something like a managed safe, also for login credentials, credit card information, etc.). And for some reason this keyring storage might not be found correctly. To give element a hint type in a terminal
<pre>
element-desktop --password-store="gnome-libsecret"
</pre>
This should greet you with a window as shown in the image.

[[File:matrix-element-startup.png|400px|center]]

After the first start the option <code>--password-store</code> is no longer required as it should be configured in your preferences now.

== Login with FAU credentials ==

To login with your valid IdM account click on (you guessed it): '''Sign In'''. The next page asks you to specify a home server<ref>Again due to the non-centralized aspects of the matrix protocol there must be a server ''your'' identity is associated with. Think of it as your email server. Everyone with an email address can send you message, despite not being registered with the same email server.</ref>, to change it to the RRZE hosted server click on '''Edit''' and input <code>matrix.fau.de</code> in the opening window under ''Other homeserver''. After hitting continue you should see this

[[File:matrix-element-fau.png|400px|center]]

By clicking on ''Continue with FAU IdM'' you will be forwarded to a webpage<ref>If your default browser is firefox you might find it giving an error message. This is because of many different security ''features''. If the admin team has not yet figured out how to circumvent this, the simplest is to temporarily change the default browser to google-chrome. For this simply open google-chrome and change the setting with the opening pop-up. To change back to firefox run this command in a terminal <code>xdg-settings set default-web-browser firefox_firefox.desktop</code></ref>

==Securing Key==

'''Important:''' Do not skip this step or you might lose access to your messages!

With your newly activated account a secure key will be stored. This key represents you within the matrix network. If you lose this key ''you'' will have to create a different key which authenticates you. This has two consequences: All logins on other devices are reset (not so dramatic), and you will not be able to decrypt any messages that you (your previous you) send! Quite problematic. To help with this follow the steps prompted for. If they are not, click on the button in the top left corner (a letter for your initial). There select ''All settings'' and go to ''Encryption''. The checkbox for ''Key storage'' should be checked and you can add a recovery key below. You will be asked for a password and a key will be shown. '''Both''' are independently able to recover your identity and should not be shared with anyone. So store them at a safe place.

==Login on other device==

When you login from another device you will likely get a message saying something along the lines of ''unverified identity''. You can use the password form the key storage from the section above to set your identity, or you can use your already verified device. Simply follow the instructions on screen. You can also skip identifying, but this will not allow you to see encrypted messages that have been send to you, nor can you send encrypted messages (but not all chats are encrypted)!

==Final steps==

Explore! You can create private and groups chats and explore rooms. Of course you can also create your own rooms, with different visibility settings etc. For Remeisens a room exists [https://matrix.to/#/!lwQEiefDYDQwfkZxgH:fau.de?via=fau.de here]

===LaTeX integration===

One handy feature of elements is the ability to chat with latex commands. This is currently an experimental feature which needs to be enabled by hand. To do this create a file here <code>~/.config/Element/config.json</code> which contains the following

<pre>
{
"features": {
"feature_latex_maths": true
}
}
</pre>

After restarting <code>element-desktop</code> you can type things like <code>$E = mc^2$</code> and they will appear nicely typeset.

===Some more information===

If you want to know more about matrix and why and how it does things you might find this beginner friendly introduction interesting: [https://joinmatrix.org/guide/ joinmatrix].

===Joining rooms outside and let others join your rooms===

You can join (public) rooms on other servers by searching them. There is a small drop-down menu that allows you to change other servers and search by names. In the same menu you can also add other external servers, this is relevant if you want to join groups hosted in other university networks.

For users outside of FAU to join and where their network does not provide a matrix instance it is simplest to join [https://matrix.org matrix.org] and register there. Just make sure that when you create a room which is meant to be accessed by someone from the outside this access is not restricted (under the advanced settings of the room creation dialog).

That's it, happy chatting :)

==Notes==
<references/>
[[Category:Software]]

Chat

2026-01-14T11:53:36Z

Stierhof:

Chat

2026-01-14T11:37:56Z

Stierhof:

Chat

2026-01-14T11:25:21Z

Stierhof: Created page with "The university hosts a matrix server which can be used with the university internal credentials. This page gives a quick introduction on how to setup 'element', the reference..."

File:Matrix-element-fau.png

2026-01-14T11:04:59Z

Stierhof: Matrix FAU server setting

== Summary ==
Matrix FAU server setting

File:Matrix-element-startup.png

2026-01-14T10:39:47Z

Stierhof: Matrix/Element Desktop startup screen

== Summary ==
Matrix/Element Desktop startup screen

Matrix Chat

2026-01-14T08:07:56Z

Stierhof: Created page with "This are some notes how to setup a matrix chat using element (reminder matrix is a protocol and element just one implementation, but for now the most matured one). == Install..."

This are some notes how to setup a matrix chat using element (reminder matrix is a protocol and element just one implementation, but for now the most matured one).

== Install element on Ubuntu ==

<pre>
# probably there already
sudo apt install -y wget apt-transport-https

# add signatures to keyring
sudo wget -O /usr/share/keyrings/element-io-archive-keyring.gpg https://packages.element.io/debian/element-io-archive-keyring.gpg

# fetch package list
echo "deb [signed-by=/usr/share/keyrings/element-io-archive-keyring.gpg] https://packages.element.io/debian/ default main" | sudo tee /etc/apt/sources.list.d/element-io.list

# update world
sudo apt update

# install
sudo apt install element-desktop
</pre>

Requires of course root privileges. Probably will be added to puppet anyway.

[[Category:Admin]]

Puppet git integration

2025-12-04T13:40:07Z

Stierhof:

Puppet distributes the configuration for our cluster from a git repository ([https://www.sternwarte.uni-erlangen.de/gitlab/Admins/puppet puppet-git]). The gitlab runner that is used for admin related repositories is setup to execute the code on the machine where the puppet server is running. See /etc/gitlab-runner/config.toml on the gitlab server. In there are the credential information given for a root login to the puppet server. The CI pipeline copies the contents of the repository to the relevant directory structure.

To run command on the target machine (where the puppet server is running) the key files for root have to be set. That is, the public key must be added to /root/.ssh/authorized_keys and the finger-print of the server must be added to /home_local/ubuntuadmin/.ssh/know_hosts (on the machine that servers gitlab).

[[Category:Puppet]][[Category:Admin]]

Setup puppet

2025-12-03T09:37:03Z

Stierhof:

Puppet is a configuration management software which has a server providing the configuration and agents which request configuration from the server.

Puppet itself is now (as of 2023) owned by Perforce and they decided to move it to closed-source. The community did not like that so they came up with a fork called 'openvox' (see [https://thenewstack.io/openvox-the-community-driven-fork-of-puppet-has-arrived/ this article] and [https://github.com/OpenVoxProject/openvox the github of the fork]).

For legal reasons the package is renamed to openvox, but all commands and paths including 'puppet' are still kept (as of 2025).

== Installing puppet ==

To install puppet three components are required: The agent, the server, and the database (not really required, but helps to reduce load).

=== Installing the server ===

Essentially follow [https://voxpupuli.org/openvox/install/ this page], that is, download the .dep file and install openvox-server. If puppet was installed before on this machine it has to be removed first. I had some issues keeping the old configuration. I think this is due to configuration being stored in some generated files. I was successful by backing only relevant config files and delete all folders related to puppet (/etc/puppetlabs, /opt/puppetlabs, /var/puppetlabs).

Once the server is installed change /etc/puppetlabs/puppet/puppet.conf to

<pre>
[main]
server = puppet.service
runtimeout = 10800

[agent]
splay=true
environment=noble
runinterval=1800
number_of_facts_soft_limit=4096

[server]
server = puppet.service
ca_server = puppet.service
vardir = /opt/puppetlabs/server/data/puppetserver
logdir = /var/log/puppetlabs/puppetserver
rundir = /var/run/puppetlabs/puppetserver
pidfile = /var/run/puppetlabs/puppetserver/puppetserver.pid
codedir = /etc/puppetlabs/code
tagmap = $confdir/tagmail.conf
reports = tagmail,puppetdb
storeconfigs = true
storeconfigs_backend = puppetdb
allow_duplicate_certs = true
dns_alt_names = puppet.service
</pre>

(here 'puppet.service' is the server name puppet is supposed to run on, change accordingly, dns_alt_names allows us to have the dns record changed only and certificates are still matching).

Normally puppet requires signed certificates so there is control of who accesses the configuration. This is a bit annoying, so we allow auto-signing. For this add /etc/puppetlabs/puppet/autosign.conf with

<pre>
*.sternwarte.uni-erlangen.de
</pre>

to allow all hosts matching this pattern to get a config.

A 'systemctl start puppetserver' should spin up the server from here.

=== Installing agent ===

For the agent on each machine install 'openvox-agent' (similar to server, better get rid of previous puppet stuff). Add the same config (the <code>[server]</code> section is not needed), change the environment accordingly. And fire it up with 'systemctl start puppet'.

Now in principle a 'sudo /opt/puppetlabs/bin/puppet agent -t' requests the configuration for the current node. However, this will fail as we set the server to use the puppetdb, which is not yet there. So to finish of we need to

=== Install the puppet database ===

This requires that postgreSQL is installed on the server (we have the db and the puppetserver on the same machine). Setup a table for puppetdb, for this change to the postgres users (sudo su - postgres). Create a table with <code>createuser -DRSP puppetdb</code>. This will ask for a password (twice).

Now create the database with <code>createdb -E UTF8 -O puppetdb puppetdb</code>.

Install necessary addons with <code>psql puppetdb -c 'create extension pg_trgm'</code> and leave the postgres user.

For puppet check latest versions with

<pre>
sudo /opt/puppetlabs/bin/puppet resource package openvoxdb ensure=latest
sudo /opt/puppetlabs/bin/puppet resource package openvoxdb-termini ensure=latest
</pre>

Notice the package names!

It is necessary to add the config values to /etc/puppetlabs/puppetdb/conf.d/database.ini as

<pre>
[database]

# The database address, i.e. //HOST:PORT/DATABASE_NAME
subname = //localhost:5432/puppetdb

# Connect as a specific user
username = puppetdb

# Use a specific password
password = RemeisPuppet

# How often (in minutes) to compact the database
# gc-interval = 60
</pre>

Password must be the one for the puppetdb database entered in postgreSQL before.

Check setup with <code>sudo /opt/puppetlabs/bin/puppetdb ssl-setup</code>

and add /etc/puppetlabs/puppet/puppetdb.conf with

<pre>
[main]

server_urls = https://puppet.service:8081
</pre>

Lastly, add /etc/puppetlabs/puppet/routes.yaml with

<pre>
master:
facts:
terminus: puppetdb
cache: yaml
</pre>

and spin up the database with 'systemctl start puppetdb' (if this does not complete chances are that the database PW is wrong, unfortunately this does not error meaningfully per default).

Restart the server ('systemctl restart puppetserver') and run puppet from a node again. Everything should work now!

[[Category:Puppet]]
[[Category:Admin]]

Puppet git integration

2025-12-03T09:36:24Z

Stierhof:

LDAP

2025-12-02T15:21:26Z

Stierhof:

[[Category:Admin]]
= LDAP =
The LDAP server at Remeis is running on vela. The service itself is called ''slapd''. A backup LDAP server is running on libra.

Every interaction with the ''slapd'' requires root access.

== Where LDAP is used ==
LDAP is not only used for the authentication to login into the variety of machines at Remeis. Also a lot of other services/scripts use ldap:

* This wiki
* The internal webpage
* [[GitLab]]
* [[#phpLDAPadmin|phpLDAPadmin]]
* The <code>who_takes_the_minutes.pl</code> script of the X-ray group
* The ''cgnotifier'' for the [[cgroups]]

== Configuration ==

=== Config files ===
The main LDAP configuration file is <code>/etc/ldap.conf</code>. Note that this is not the default location for the configuration file. Therefore the defaults for the slapd are changed in <code>/etc/default/slapd</code>, see the entry <code>SLAPD_CONF</code>. The <code>/etc/ldap.conf</code> is also present on all the clients and specifies via IP-Address which LDAP server to contact for authentication. The LDAP requests are then handled on taurus by the ''slapd'' which is configured via <code>/etc/ldap/slapd.conf</code>.

=== phpLDAPadmin ===
phpLDAPadmin is a web interface based on [https://de.wikipedia.org/wiki/PHP PHP] which allows simple modifications to the directory for example to [[:Category:Admin#Add new Users|add new users]] or change group memberships. It is accessible via the [https://www.sternwarte.uni-erlangen.de/intern/phpldapadmin/ internal webpages] and only out of the network at the Remeis observatory.

==== Configuration of phpLADPadmin ====
The configuration files for phpLDAPadmin are located in <code>/etc/phpldapadmin/</code> on the webserver, in this case [[cetus]]. The important file is <code>config.php</code> which holds information about which LDAP servers can be queried, in this case [[taurus]].

== Starting/Stopping the service ==
The slapd can be stopped via [https://de.wikipedia.org/wiki/Systemd systemd]:
<pre>
systemctl stop slapd
</pre>
'''Important:''' If you do so no authentication on the whole cluster is possible anymore. You can not open a new shell on any host until you start the service again!

Starting the ''slapd'':
<pre>
systemctl start slapd
</pre>
You also can have a look at the output produced by the running service via
<pre>
systemctl status slapd
</pre>

== Database ==
The [https://en.wikipedia.org/wiki/Berkeley_DB Berkeley DB] containing all the active directory information is located at <code>/var/lib/ldap</code>. Files in this directory must not be touched manually in any way. The only secure way to see the content of the database is by using ''slapcat''. For example
<pre>
slapcat -f /etc/ldap/slapd.conf
</pre>
will show all entries of the database.

== Backup ==
Each night the database is dumped to <code>/data/system/backup/ldap/</code> via a cronjob in <code>/etc/cron.d/ldap_backup</code>. Also a tarball of the ''slapd'' and <code>ldap.conf</code> is created there. All backups older than 14 days are deleted.

== Migration ==

See also https://serverfault.com/questions/730088/how-to-migrate-ldap-database-schema-configuration-to-other-machine

=== Step 1: Export configuration trees and database ===

'''From old provider (`vela`)'''
<pre>
sudo slapcat -n 0 -l ldap_config_vela.ldif
sudo slapcat -n 1 -l ldap_data_vela.ldif
</pre>

'''From old consumer (`libra`)'''
<pre>
sudo slapcat -n 0 -l ldap_config_libra.ldif
</pre>

=== Step 2: Save certificates ===

'''vela:'''
<pre>
/etc/ssl/certs/openldap.pem
/etc/ldap/grus_slapd_cert.pem
/etc/ldap/grus_slapd_key.pem
</pre>

'''libra:'''
<pre>
/etc/ssl/certs/openldap.pem
/etc/ldap/phoenix_slapd_cert.pem
/etc/ldap/phoenix_slapd_key.pem
</pre>

=== Step 3: Set up new provider ===

'''Install packages'''
<pre>
sudo apt install slapd ldap-utils
</pre>

'''Stop slapd and remove existing configuration and data'''
<pre>
sudo systemctl stop slapd
sudo rm -rf /etc/ldap/slapd.d/*
sudo rm -rf /var/lib/ldap/*
</pre>

'''Import configuration and data'''

*Important:* ldif files may need modification to be importable. One is that
eventually spaces need to be added to mask spaces (two spaces at beginning of line
collapse to one space!, 1 space to 0!!).

Further, since version 2.5 of openldap, the ppoly is included per default, so
this needs to be removed from schema files.

<pre>
sudo slapadd -n 0 -F /etc/ldap/slapd.d -l /path/to/ldap_config_vela.ldif
sudo slapadd -n 1 -l /path/to/ldap_data_vela.ldif
</pre>

'''Set ownership of /etc/ldap/slapd.d and /var/lib/ldap to openldap'''

'''Restore certificates'''
<pre>
lrwxrwxrwx 1 root root 45 Jul 10 2023 /etc/ssl/certs/openldap.pem -> /usr/local/share/ca-certificates/openldap.pem
-rw-r--r-- 1 root root 1614 Jul 10 2023 /etc/ldap/grus_slapd_cert.pem
-rw-r----- 1 root openldap 8170 Jul 10 2023 /etc/ldap/grus_slapd_key.pem
</pre>

'''Start slapd'''
<pre>
sudo systemctl start slapd
</pre>

'''Verify'''
<pre>
ldapsearch -H ldap://localhost -x -b dc=sternwarte,dc=uni-erlangen,dc=de
</pre>

=== Step 4: Set up new consumer for replication ===

'''Install packages'''
<pre>
sudo apt install slapd ldap-utils
</pre>

'''Stop slapd and remove existing configuration and data'''
<pre>
sudo systemctl stop slapd
sudo rm -rf /etc/ldap/slapd.d/*
sudo rm -rf /var/lib/ldap/*
</pre>

'''Import configuration'''
<pre>
sudo slapadd -n 0 -F /etc/ldap/slapd.d -l /path/to/ldap_config_libra.ldif
</pre>

'''Set ownership of /etc/ldap/slapd.d and /var/lib/ldap to openldap'''

'''Restore certificates''' (guess other r permission on key is wrong currently)
<pre>
lrwxrwxrwx 1 root root 45 May 13 2023 /etc/ssl/certs/openldap.pem -> /usr/local/share/ca-certificates/openldap.crt
-rw-r--r-- 1 root root 1619 Jul 11 2023 /etc/ldap/phoenix_slapd_cert.pem
-rw-r--r-- 1 root root 8180 Jul 11 2023 /etc/ldap/phoenix_slapd_key.pem
</pre>

'''Start slapd'''
<pre>
sudo systemctl start slapd
</pre>

'''Check replication'''
<pre>
journalctl -fu slapd
</pre>

'''Verify'''
<pre>
ldapsearch -H ldap://localhost -x -b dc=sternwarte,dc=uni-erlangen,dc=de
</pre>

=== Step 5: Check dependent services ===

* ldap backup
* Wiki
* Internal webpage
* Gitlab
* phpLDAPadmin (web interface)
* `who_takes_the_minutes`

2025-05-05T12:07:18Z

Stierhof:

[[Category:Internal]]

This page documents how to apply for business travel and hand in the reimbursement with the online tool accessible through [https://www.mitarbeiterservice.bayern.de/ authega]. This requires you to have an account set up. If you sign up for the first time you will be send a letter (! yes, physical letter, this can take some days) with information for the login. For further logins it is best to use a certificate file with a password.

Once logged in you can access the travel management (Reisekostenmanagement, RMS) and enter the necessary information there. Certain numbers are tied to the observatory and will always be the same, they are documented below. '''Note:''' When selecting the institution (Beschätigungsbehöde) do '''not''' use the Remeis-Observatory or any other smaller body. Instead use the general FAU entry with the number '''1519016'''!

More information for the general setup are in the [[:Media:introduction_bayrms.pdf|introductory slides]] (unfortunately only in German, but mostly with images so you should at least get the right buttons from it).

== Application for business travel ==

== Handing in reimbursement ==

== List of project funds ==

Below is a list of project funds that you might want to add (possibly a subset thereof). This are the funds the travel is paid from.

{| class="wikitable" style="margin:auto"
|+ Project numbers
|-
! Name !! Erweiterung !! Titel !! AWK !! Kostenstelle
|-
| DLR 50 OR 2309 (VF-ULX) || 7401 171 || 547 41 || || 1415151100
|-
| DLR 50 OO 2417 (THESEUS) || 7401 182 || 547 41 || || 1415151100
|-
| DLR 50 OR 2410 (VF-XMM Aafia) || 7401 186 || 547 41 || || 1415151100
|-
| DLR 50 QR 2503 (eROSITA) || 7401 188 || 547 41 || || 1415151100
|-
| DLR 50 QR 2508 (ATHENA) || 7401 191 || 547 41 || || 1415151100
|-
| DLR 50 OO 2507 (AXIS) || 7401 196 || 547 41 || || 1415151100
|-
| || || || ||
|-
| DFG WI 1860/17-2 (eRO STEP 1, P5) || 7458 208 || 547 41 || || 1415151100
|-
| DFG WI 1860/19-1 (eRO STEP 1, P6) || 7458 046 || 547 41 || || 1415151100
|-
| DFG WI 1860/20-1 (FOR 5195, P2) || 7458 065 || 547 41 || || 1415151100
|-
| DFG WI 1860/21-1 (eRO STEP 2, P7) || 7458 209 || 547 41 || || 1415151100
|-
| || || || ||
|-
| DFG overhead WI bis 2022 || 5002344 || 547 40 || PPS || 1415151100
|-
| DFG overhead WI ab 2023 || 150234 || 547 40 || PPS || 1415151100
|-
| || || || ||
|-
| ESA (DALI) || 7402 745 || 547 41 || || 1415151100
|-
| Wlms Altprojekte || 7402 304 || 547 41 || || 1415151100
|-
| ETI Förderung || 5500 245 || 547 41 || || 1415151100
|-
| || || || ||
|-
| DFG SA 2131/13-2 (eRO STEP 2, P1) || 7458 204 || 547 41 || || 1415150013
|-
| DFG SA 2131/14-2 (eRO STEP 2, P2) || 7458 205 || 547 41 || || 1415150013
|-
| DFG SA 2131/15-2 (eRO STEP 2, TP Z) || 7458 206 || 547 41 || || 1415150013
|-
| DFG SA 2131/18-1 (eROSITA Galaxien) || 7458 168 || 547 41 || || 1415150013
|-
| || || || ||
|-
| DFG overhead SA (Altprojekte) || 7459 704 || 547 41 || || 1415150013
|-
| DFG overhead SA bis 2022 || 5002391 || 547 40 || PPS || 1415150013
|-
| DFG overhead SA ab 2023 || 0150178 || 547 40 || PPS || 1415150013
|-
| || || || ||
|-
| DFG SA 4388/2-1 (Saeedi) || 7458 207 || 547 41 || || 1415150013
|-
| DFG MA 11073/1-1 (Mayer) || 7458 221 || 547 41 || || 1415150013
|-
| DFG HE 1356/70-2 (Heber) || 7458 225 || 547 41 || || 1415150000
|-
| || || || ||
|-
| 73er Titel || 061 000-6 || 547 40 || FuL || 1415150000
|-
| 72er Titel || 806 3141 || 547 41 || || 1415150000
|}

Additionally you need to specify the kind of expense (Kostenart): 685000. If the AWK is empty in the table below, do not put anything in the '''Info 1''' field. Otherwise add the given symbol.

== ''OUTDATED!'' Business and private travels ==

If you intend to combine a business trip with a vacation to save money or just because of the occasion, you need to observe a couple of issues:

* first of all, combining business and private travel is in principle nothing that the university likes
* you *need* to get the private travel authorized on the travel request form, i.e. you need to state *both* on travel request form
* obviously you will not get any reimbursement for the private part of your trip, or any extra expenses arising from your vacation
* to get reimbursement for your business part of the trip, you need to document what the business part alone would have cost. In detail this means that you need to document:
* fictitious cost of flights/train tickets/rental car/etc for the business part of the trip
* fictitious cost of flights/train tickets/etc to and from the business destination of the trip
* nevertheless you also obviously need to state your actual cost (flight tickets etc).
* the university will reimburse you only the *lesser* of your actual cost and the fictitious cost!\\ This means that if your flight would have cost 1000 Eur, but because you stayed longer for private reasons (i.e. over the weekend) and the actual flight is cheaper like 700 Eur, the university will only reimburse you 700 Eur.

Furthermore apart from the reimbursement by the university, you have also to consider the taxes: the fiscal authorities might consider such a combination of business and private trip entirely private and therefore the reimbursement as additional income. So far,
this has never happened in Bamberg to Jörns knowledge, but in principle tax
regulations state that for a trip to count as a business trip, the
business portion must outbalance the private portion. To give an
example: a 3d observing run in Australia followed by a 2 week vacation
there would probably not be seen as a business related trip (even if it
was!), even though the university would reimburse you for your flights
and the 3d per diem.
((Based on a FAQ Email sent by Jörn to allusers on April 4, 2011))

Login

2024-11-21T13:00:29Z

Stierhof:

== Issuses during update to 16.04 ==

Especially in the course of the update of 14.04 to 16.04 the following issues have turned out to happen quite often. The text was copied from Ingo's mail to the admin list.

* the .dmrc problem: if something else than "plasma" is specified in
this file in the home directory of the user, you'll get a "can not load
session" (or similar) error message. Since lightdm sort of "caches" the
value of this file in a file of its own, this can be very annoying to
sort out.

* the .Xauthority problem: can happen if a machine is newly installed
and the user has worked on that machine before the update, i.e. a wrong
key is stored in .Xauthority

* akonadi / baloo crap: if enabled, these daemons cause heavy IO load
and potentially slow down / inhibit login or make the machine barely
usable while creating the databases

* useless KDE animations: on older or weaker machines, enabling (or not
disabling) tons of KDE animations can make the machine very slow, or
might even crash the graphics driver

* reboot necessary: as it turned out in Marias case, the machine needed
a reboot. It seems that the new KDE is new more touchy w.r.t. a
necessary reboot. I.e. if KDE components have been updated by the
nightly cron jobs, the KDE/Ubuntu 16 system services (dbus et al)

apparantly do not get along very well any more causing these frozen
logins and a reboot is needed.
==> if this happens more often, we have to think about whether we can
continue with the nightly updates, or whether we do them only once a
week and have reboots afterwards (something like "reboot Monday" or
similar).

* ''possibly'' some other cron job may interfere with the new KDE causing
these frozen logins.

== Ubuntu 20.04 Issues ==

For some reason it can happen that for a particular user on a particular machine lightdm (login manager) decides to load the gnome session (albeit it should load xfce per default). It does so despite no full gnome desktop environment is installed. It seems that somehow the d-bus is wrongly configured (?) or started (?), not sure. Anyway, the effect is that even logout or restart does not fix this. The user is greeted with a pretty blank gnome desktop environment running on top of xfce (the later is therefore inaccessible).

This seems to fix this:
<code>
sudo dbus-send --system --type=method_call --print-reply --dest=org.freedesktop.Accounts /org/freedesktop/Accounts/User<UID> org.freedesktop.Accounts.User.SetXSession string:xfce
</code>
make sure to replace <code><UID></code> with the affected users id.

[[Category:Admin]]

Login

2024-11-21T12:55:27Z

Stierhof:

== Issuses during update to 14.04 ==

Especially in the course of the update of 14.04 to 16.04 the following issues have turned out to happen quite often. The text was copied from Ingo's mail to the admin list.

* the .dmrc problem: if something else than "plasma" is specified in
this file in the home directory of the user, you'll get a "can not load
session" (or similar) error message. Since lightdm sort of "caches" the
value of this file in a file of its own, this can be very annoying to
sort out.

* the .Xauthority problem: can happen if a machine is newly installed
and the user has worked on that machine before the update, i.e. a wrong
key is stored in .Xauthority

* akonadi / baloo crap: if enabled, these daemons cause heavy IO load
and potentially slow down / inhibit login or make the machine barely
usable while creating the databases

* useless KDE animations: on older or weaker machines, enabling (or not
disabling) tons of KDE animations can make the machine very slow, or
might even crash the graphics driver

* reboot necessary: as it turned out in Marias case, the machine needed
a reboot. It seems that the new KDE is new more touchy w.r.t. a
necessary reboot. I.e. if KDE components have been updated by the
nightly cron jobs, the KDE/Ubuntu 16 system services (dbus et al)

apparantly do not get along very well any more causing these frozen
logins and a reboot is needed.
==> if this happens more often, we have to think about whether we can
continue with the nightly updates, or whether we do them only once a
week and have reboots afterwards (something like "reboot Monday" or
similar).

* ''possibly'' some other cron job may interfere with the new KDE causing
these frozen logins.

== Ubuntu 20.04 Issues ==

For some reason it can happen that for a particular user on a particular machine lightdm (login manager) decides to load the gnome session (albeit it should load xfce per default). It does so despite no full gnome desktop environment is installed. It seems that somehow the d-bus is wrongly configured (?) or started (?), not sure. Anyway, the effect is that even logout or restart does not fix this. The user is greeted with a pretty blank gnome desktop environment running on top of xfce (the later is therefore inaccessible).

This seems to fix this:
<code>
sudo dbus-send --system --type=method_call --print-reply --dest=org.freedesktop.Accounts /org/freedesktop/Accounts/User<UID> org.freedesktop.Accounts.User.SetXSession string:xfce
</code>
make sure to replace <code><UID></code> with the affected users id.

[[Category:Admin]]

Login

2024-11-21T12:54:01Z

Stierhof:

# Issuses during update to 14.04

Especially in the course of the update of 14.04 to 16.04 the following issues have turned out to happen quite often. The text was copied from Ingo's mail to the admin list.

* the .dmrc problem: if something else than "plasma" is specified in
this file in the home directory of the user, you'll get a "can not load
session" (or similar) error message. Since lightdm sort of "caches" the
value of this file in a file of its own, this can be very annoying to
sort out.

* the .Xauthority problem: can happen if a machine is newly installed
and the user has worked on that machine before the update, i.e. a wrong
key is stored in .Xauthority

* akonadi / baloo crap: if enabled, these daemons cause heavy IO load
and potentially slow down / inhibit login or make the machine barely
usable while creating the databases

* useless KDE animations: on older or weaker machines, enabling (or not
disabling) tons of KDE animations can make the machine very slow, or
might even crash the graphics driver

* reboot necessary: as it turned out in Marias case, the machine needed
a reboot. It seems that the new KDE is new more touchy w.r.t. a
necessary reboot. I.e. if KDE components have been updated by the
nightly cron jobs, the KDE/Ubuntu 16 system services (dbus et al)

apparantly do not get along very well any more causing these frozen
logins and a reboot is needed.
==> if this happens more often, we have to think about whether we can
continue with the nightly updates, or whether we do them only once a
week and have reboots afterwards (something like "reboot Monday" or
similar).

* ''possibly'' some other cron job may interfere with the new KDE causing
these frozen logins.

# Ubuntu 20.04 Issues

For some reason it can happen that for a particular user on a particular machine lightdm (login manager) decides to load the gnome session (albeit it should load xfce per default). It does so despite no full gnome desktop environment is installed. It seems that somehow the d-bus is wrongly configured (?) or started (?), not sure. Anyway, the effect is that even logout or restart does not fix this. The user is greeted with a pretty blank gnome desktop environment running on top of xfce (the later is therefore inaccessible).

This seems to fix this:
<code>
sudo dbus-send --system --type=method_call --print-reply --dest=org.freedesktop.Accounts /org/freedesktop/Accounts/User<UID> org.freedesktop.Accounts.User.SetXSession string:xfce
</code>
make sure to replace <code><UID></code> with the affected users id.

[[Category:Admin]]

WebCalendar

2024-09-06T09:13:26Z

Stierhof:

This is a lose collection of information regarding the web calendar. Currently we use [https://github.com/craigk5n/webcalendar?tab=readme-ov-file k5n's php implementation] with some custom changes (which might be possible to do in a better way, but I have no clue so far).

== Backing up database ==

The calendar user has no rights so you need to know the db admin login. Then you can do
```
mysqldump -uroot -p Calendar_I > Calendar_I.sql
```

Calendar_I is what was as of this writing. Check include/settings.php in the WebCalendar folder to see what is actually used right now.

== Update script ==

After backing the data base unpack the new version into a new folder, set the apache address (remember it is in puppet), and go through the install script. Make sure that 'includes/' is read/writeable by www-data! (and also the parent folder).

== PHP version ==

For PHP v7.4 only WebCalendar v1.9.8 seems to work. They are in the process of updating to PHP v8!

== LDAP settings ==

After doing the initialization or updating of the database we need to connect to ldap. If you did not select LDAP autehtication during setup you can change that in 'includes/settings.php'. Adjust the settings in 'includes/auth-settings.php' such that:

<pre>
$user_can_update_password = false;
$admin_can_add_user = false;
$admin_can_delete_user = false;
...
$ldap_server = '<server address>';
...
$set_lda-_version = true;
...
$ldap_base_dn = 'ou=People,dc=sternwarte,dc=uni-erlangen,dc=de';
...
$ldap_admin_group_name = 'cn=leitung,ou=local,ou=Group,dc=sternwarte,dc=uni-erlangen,dc=de';
...
$ldap_user_filter = '(|(objectclass=remeisperson)(uid=webmaster))'; // only allow real people, but also webmaster
</pre>

== Customization ==

We do small changes to guide the users:

'includes/menu.php' change
<pre>
<a class="nav-link" href="<?php echo $logout_url; ?>">Logout</a>
</pre>
to
<pre>
<a class="nav-link" href="<?php echo $logout_url; ?>"><?php if ($login == '__public__') echo \
'Login'; else echo 'Logout';?></a>
</pre>

There are changes in 'includes/functions.php' regarding the __internal__ fake user. Check older WebCalendar files what was done. Same goes for 'includes/classes/WebCalendar.php', includes/translate.php', 'includes/user-ldap.php', 'edit_entry.php' and 'admin.php'.

Lastly, it seems that the entry edit queries only can handle 1 selected category (or none) but the page allows to select multiple. To change, edit 'edit_entry.php' (search for "Edit Categories") and change all buttons from "checkbox" to "radio" and remove the category id in the name for the radio buttons to communicate.

[[Category:Web Admin]]

WebCalendar

2024-08-19T08:27:22Z

Stierhof:

WebCalendar

2024-08-09T15:43:08Z

Stierhof:

This is a lose collection of information regarding the web calendar. Currently we use [https://github.com/craigk5n/webcalendar?tab=readme-ov-file k5n's php implementation] with some custom changes (which might be possible to do in a better way, but I have no clue so far).

== Backing up database

The calendar user has no rights so you need to know the db admin login. Then you can do
```
mysqldump -uroot -p Calendar_I > Calendar_I.sql
```

Calendar_I is what was as of this writing. Check include/settings.php in the WebCalendar folder to see what is actually used right now.

== Update script ==

After backing the data base unpack the new version into a new folder, set the apache address (remember it is in puppet), and go through the install script. Make sure that 'includes/' is read/writeable by www-data! (and also the parent folder).

== PHP version ==

For PHP v7.4 only WebCalendar v1.9.8 seems to work. They are in the process of updating to PHP v8!

== LDAP settings ==

After doing the initialization or updating of the database we need to connect to ldap. If you did not select LDAP autehtication during setup you can change that in 'includes/settings.php'. Adjust the settings in 'includes/auth-settings.php' such that:

<pre>
$user_can_update_password = false;
$admin_can_add_user = false;
$admin_can_delete_user = false;
...
$ldap_server = '<server address>';
...
$set_lda-_version = true;
...
$ldap_base_dn = 'ou=People,dc=sternwarte,dc=uni-erlangen,dc=de';
...
$ldap_admin_group_name = 'cn=leitung,ou=local,ou=Group,dc=sternwarte,dc=uni-erlangen,dc=de';
...
$ldap_user_filter = '(|(objectclass=remeisperson)(uid=webmaster))'; // only allow real people, but also webmaster
</pre>

== Customization ==

We do small changes to guide the users:

'includes/menu.php' change
<pre>
<a class="nav-link" href="<?php echo $logout_url; ?>">Logout</a>
</pre>
to
<pre>
<a class="nav-link" href="<?php echo $logout_url; ?>"><?php if ($login == '__public__') echo \
'Login'; else echo 'Logout';?></a>
</pre>

There are changes in 'includes/functions.php' regarding the __internal__ fake user. Check older WebCalendar files what was done. Same goes for 'includes/classes/WebCalendar.php', includes/translate.php', 'includes/user-ldap.php', 'edit_entry.php' and 'admin.php'.

[[Category:Web Admin]]

WebCalendar

2024-08-09T15:30:14Z

Stierhof:

This is a lose collection of information regarding the web calendar. Currently we use [https://github.com/craigk5n/webcalendar?tab=readme-ov-file k5n's php implementation] with some custom changes (which might be possible to do in a better way, but I have no clue so far).

== Backing up database

The calendar user has no rights so you need to know the db admin login. Then you can do
```
mysqldump -uroot -p Calendar_I > Calendar_I.sql
```

Calendar_I is what was as of this writing. Check include/settings.php in the WebCalendar folder to see what is actually used right now.

== Update script ==

After backing the data base unpack the new version into a new folder, set the apache address (remember it is in puppet), and go through the install script. Make sure that 'includes/' is read/writeable by www-data! (and also the parent folder).

== PHP version ==

For PHP v7.4 only WebCalendar v1.9.8 seems to work. They are in the process of updating to PHP v8!

== LDAP settings ==

After doing the initialization or updating of the database we need to connect to ldap. If you did not select LDAP autehtication during setup you can change that in 'includes/settings.php'. Adjust the settings in 'includes/auth-settings.php' such that:

<pre>
$user_can_update_password = false;
$admin_can_add_user = false;
$admin_can_delete_user = false;
...
$ldap_server = '<server address>';
...
$set_lda-_version = true;
...
$ldap_base_dn = 'ou=People,dc=sternwarte,dc=uni-erlangen,dc=de';
...
$ldap_admin_group_name = 'cn=leitung,ou=local,ou=Group,dc=sternwarte,dc=uni-erlangen,dc=de';
...
$ldap_user_filter = '(|(objectclass=remeisperson)(uid=webmaster))'; // only allow real people, but also webmaster
</pre>

== Customization ==

We do small changes to guide the users:

'includes/menu.php' change
<pre>
<a class="nav-link" href="<?php echo $logout_url; ?>">Logout</a>
</pre>
to
<pre>
<a class="nav-link" href="<?php echo $logout_url; ?>"><?php if ($login == '__public__') echo \
'Login'; else echo 'Logout';?></a>
</pre>

There are changes in 'includes/functions.php' regarding the __internal__ fake user. Check older WebCalendar files what was done. Same goes for 'includes/classes/WebCalendar.php', includes/translate.php', 'includes/user-ldap.php' and 'admin.php'.

[[Category:Web Admin]]

WebCalendar

2024-08-09T15:09:44Z

Stierhof:

This is a lose collection of information regarding the web calendar. Currently we use [https://github.com/craigk5n/webcalendar?tab=readme-ov-file k5n's php implementation] with some custom changes (which might be possible to do in a better way, but I have no clue so far).

== Backing up database

The calendar user has no rights so you need to know the db admin login. Then you can do
```
mysqldump -uroot -p Calendar_I > Calendar_I.sql
```

Calendar_I is what was as of this writing. Check include/settings.php in the WebCalendar folder to see what is actually used right now.

== Update script ==

After backing the data base unpack the new version into a new folder, set the apache address (remember it is in puppet), and go through the install script. Make sure that 'includes/' is read/writeable by www-data! (and also the parent folder).

== PHP version ==

For PHP v7.4 only WebCalendar v1.9.8 seems to work. They are in the process of updating to PHP v8!

== LDAP settings ==

After doing the initialization or updating of the database we need to connect to ldap. If you did not select LDAP autehtication during setup you can change that in 'includes/settings.php'. Adjust the settings in 'includes/auth-settings.php' such that:

<pre>
$user_can_update_password = false;
$admin_can_add_user = false;
$admin_can_delete_user = false;
...
$ldap_server = '<server address>';
...
$set_lda-_version = true;
...
$ldap_base_dn = 'ou=People,dc=sternwarte,dc=uni-erlangen,dc=de';
...
$ldap_admin_group_name = 'cn=leitung,ou=local,ou=Group,dc=sternwarte,dc=uni-erlangen,dc=de';
...
$ldap_user_filter = '(|(objectclass=remeisperson)(uid=webmaster))'; // only allow real people, but also webmaster
</pre>

== Customization ==

We do small changes to guide the users:

'includes/menu.php' change
<pre>
<a class="nav-link" href="<?php echo $logout_url; ?>">Logout</a>
</pre>
to
<pre>
<a class="nav-link" href="<?php echo $logout_url; ?>"><?php if ($login == '__public__') echo \
'Login'; else echo 'Logout';?></a>
</pre>

[[Category:Web Admin]]