---
type: overview
title: Project Overview
tags: []
related: []
created: 2026-06-30
updated: 2026-06-30
---

# Overview

This wiki serves as a knowledge base for documenting various technical entities, concepts, and institutional infrastructures. It currently tracks a wide range of software tools, organizational structures, and technical standards.

A significant portion of the current content focuses on academic IT infrastructure, specifically the service ecosystem of the **Universität Greifswald**. This includes the operations of the **Universitätsrechenzentrum (URZ)**, which manages the **Campus-IT** environment. The wiki documents the integration of standard academic tools (such as Moodle, Nextcloud, eduroam) alongside specialized internal services like **GrypsTube**, **easydb**, and the **Groupware** collaboration platform.

The wiki provides extensive documentation on the URZ's **Device Management System**, which utilizes tools like **opsi** and **FileWave** to provide tiered support levels (**Vollservice** and **Basisservice**) for Windows, Ubuntu, and macOS devices. For Windows, the **Vollservice** model is detailed as a system that ensures data redundancy and mobility through **Folder Redirection** (mapping local folders to a central **Home Directory**) and **Server-stored Profiles**. This architecture allows for seamless hardware replacement and centralized application updates that occur during the system boot process.

Furthermore, the URZ extends its support capabilities through **Remote Support** services. By utilizing **RustDesk**, the URZ can provide graphical remote control for staff devices across Windows, Linux, and macOS. The wiki details the specific technical requirements for this implementation, including the use of a dedicated **ID-Server and Key configuration** to route traffic through university infrastructure, the necessity of a **Relay Service**, and the critical **macOS system permissions** (Accessibility and Screen Recording) required for the software to function.

The university also employs a centralized **Print Management System** powered by **PaperCut**. This system utilizes **Virtual Printers** to decouple job submission from physical hardware, requiring **Print Release and Authentication** (via ID cards or a WebClient) before documents are printed. This infrastructure allows for campus-wide printing flexibility and institutional cost control. The wiki documents the physical distribution of these devices, distinguishing between **Student Devices** (open access) and **Staff Devices** (restricted access). For staff devices, a distinction is made between **Central Billing** and non-centrally billed devices, the latter of which requires coordination with the **Referat Beschaffung**. Additionally, the wiki documents the financial administration of this system, including the **Credit Reimbursement** (Guthabenerstattung) process. 

For client-side connectivity to the central system, the wiki provides detailed configuration guides for multiple operating systems. For Linux users, the system requires the installation of a specific PaperCut client (dependent on **JRE 11**) and the configuration of a virtual printer via **CUPS** and **Ghostscript**, utilizing the **Ricoh MP C3004 PXL** driver and the **Internet Printing Protocol (HTTPS)**. For macOS users, a similar setup is required using **CUPS** and **Ghostscript**, though it necessitates the manual activation of the CUPS Web Interface via the terminal (`cupsctl WebInterface=yes`) and the use of the **Generic PostScript Printer** driver. For Windows users, the **PaperCut Windows Client** must be installed with administrator privileges, and a virtual printer is added via a specific HTTPS path. Driver selection for Windows depends on the hardware architecture: standard x64 systems use the Ricoh Universal PCL6 driver, while ARM-based devices (e.g., Microsoft Surface Pro) must use the **Microsoft PCL6 Class Driver** due to compatibility issues.

Additionally, the wiki covers foundational identity and security concepts used in research and education networks, such as the **Zentraler Nutzeraccount** and **DFN-PKI Zertifikate**. The current implementation of PKI services is managed via the **GÉANT Trusted Certificate Service (TCS)**, with **HARICA** serving as the primary certificate provider. The wiki distinguishes between **User Certificates** (which are further divided into **E-mail Certificates** for S/MIME signatures and certificates for internal university applications), **Group Certificates**, and **Server Certificates**. 

To ensure operational independence from external providers, the URZ maintains its own internal Certificate Authority, **UniHGW-CA**. This internal CA is used for university-internal web servers and is the target for the migration of VPN user certificates. The wiki highlights the critical distinction of **CA Trust Anchoring**, noting that while HARICA certificates are globally trusted, UniHGW-CA certificates are not pre-installed in browsers or email clients and are therefore unsuitable for public-facing services.

Server certificates are provisioned through a specific workflow involving the generation of a **Certificate Signing Request (CSR)**. The wiki documents multiple implementation paths for this, including the use of **OpenSSL** and a detailed workflow for **Microsoft IIS** on **Windows Server 2022**. For OpenSSL deployments, the URZ recommends modern **EC Keys** (`secp384r1`), though **RSA Keys** (4096-bit) must be used for services requiring **Key Encipherment**, such as **Shibboleth**. The IIS process involves creating the request within the IIS Manager, adhering to strict naming conventions (e.g., avoiding umlauts in "Universitaet Greifswald"), and completing the request after the certificate is issued by the CA. For deployment, the use of **PEM bundles** is recommended to ensure the complete certificate chain is preserved.

The wiki also includes specific technical implementation guides for these security services, such as the detailed processes for importing certificates into email clients. This includes the use of **.p12 files** to enable **S/MIME** (Secure/Multipurpose Internet Mail Extensions) for digital signatures and end-to-end encryption in **Microsoft Outlook**, **Mozilla Thunderbird**, and the **Groupware Webmailer**. Support for these deployments is centralized through the URZ ticket system and a dedicated Campus-IT hotline.

The wiki further documents the **Central Email Service**, detailing the technical parameters for IMAP and SMTP access using STARTTLS encryption. It clarifies the role of the **Groupware** system as the central hub for Webmail access and the management of email-specific settings such as out-of-office notifications and forwarding. The URZ explicitly recommends **Mozilla Thunderbird** as the preferred client for this service, while providing support for other common platforms including Outlook, iOS, and Android. For Android users, the URZ specifically provides guidance for the **K-9 Mail** client to ensure correct security and server configuration. For iOS users, the URZ provides both a manual configuration path and an automated **Configuration Profile** (`.mobileconfig`) to streamline the setup of email, while noting that manual **Exchange** configuration is required for calendar synchronization. For macOS users, the wiki provides specific guidance for the native Mail app, emphasizing the requirement for macOS 10.12+ for TLSv1.2 support and the necessity of manually configuring the SMTP port to 587.

Recent updates emphasize the strict enforcement of **Data Privacy Compliance** regarding email clients. Specifically, the URZ prohibits the use of the "New Outlook" app due to unauthorized data transmission to Microsoft, permitting only "Outlook Classic" (LTSC) until a hard deadline of October 9, 2029. This underscores the university's commitment to data sovereignty and its preference for open-source, privacy-compliant alternatives like Mozilla Thunderbird. The university further enhances this ecosystem by integrating **Nextcloud** for cloud storage, specifically allowing Thunderbird users to utilize the **NC Connector** to send large files via download links (Filelink), thereby bypassing email size restrictions while maintaining data sovereignty.

The wiki also defines the overarching framework for **Email Security**, emphasizing the distinction between content protection (via encryption) and sender verification (via digital signatures). This framework integrates the use of PKI certificates and provides a centralized support structure through the URZ to mitigate threats such as phishing and unauthorized account access. It specifically details the "red flags" of phishing—such as mismatched sender addresses and double file extensions—and the critical importance of using central file servers for ransomware recovery. The wiki now includes detailed operational workflows for using S/MIME in Microsoft Outlook, the use of the **DFN-Adressbuch** for public key retrieval and the necessity of updating contacts to maintain current encryption keys. It also details the specific operational steps for **Mozilla Thunderbird**, distinguishing between the automatic nature of digital signatures and the manual requirement for encryption, identified by a lock icon in the subject line. This extends to the verification of received signatures, where users are instructed to look for the "seal" icon in Outlook and verify the sender's address to ensure email authenticity. It further provides a concrete technical rule for identifying legitimate university websites: verifying that the domain is `uni-greifswald.de` and that the first forward slash immediately follows the `.de` suffix.

Most recently, the wiki has expanded to cover the risks of **Unauthorized Email Clients**. The URZ identifies certain applications as spyware that exfiltrate credentials and mirror mailboxes to external servers. This has led to a strict prohibition of clients like Edison Mail+, bluemail, and non-LTSC versions of Microsoft Outlook, with a defined remediation process for affected users involving account removal, VPN checks, and password resets.

The wiki now also documents the **Mailing List Server** infrastructure, powered by **Sympa**. This service allows for the creation of **Discussion Lists** for interactive communication and **Distribution Lists** for automated broadcasting to large groups, including student self-governance bodies. The system enforces a minimum threshold of 10 members for formal list creation, directing smaller groups to use functional accounts with **Sieve rules**. Requests for these lists are managed through the **UMS** account management system, following strict naming conventions based on the group's purpose (e.g., projects, student councils, or academic subjects).

The wiki has further expanded to detail the **Spam and Virus Protection** infrastructure. This includes the use of **Greylisting** and real-time scanning for all email traffic (incoming, outgoing, and internal). The URZ employs a strict "reject-at-gate" policy where non-scannable attachments and detected threats are rejected immediately, avoiding the need for quarantine zones. To prevent the abuse of compromised accounts, the system enforces **Ratelimits** (200 emails per 24h; 300 recipients per hour), which can be temporarily disabled via the **UMS**. The URZ also emphasizes the distinction between mass-spam and targeted **Phishing**, noting that the latter often bypasses standard filters and requires manual reporting and individual filtering. This protection is further reinforced by a comprehensive list of **Blocked Email Attachments**, which prohibits high-risk file types such as executables, scripts, and legacy Office formats to minimize the attack surface for malware and ransomware.

Additionally, the wiki now documents the **Zentrales Adressbuch** (Central Address Book), an LDAP-based directory service that allows users to retrieve employee contact information. This service is integrated into the university's email ecosystem but is strictly limited to access from within the university network. It now includes specific configuration guides for macOS users to integrate this directory into the native Contacts application and detailed LDAP parameters for integration with Microsoft Outlook. Most recently, the wiki has added detailed configuration steps for **Mozilla Thunderbird**, including the necessary LDAP server parameters and a critical attribute mapping adjustment to ensure the primary email address is correctly identified.

The wiki also covers **Instant Messaging** services provided by the URZ, offering real-time text-based communication through the **Matrix** and **XMPP/Jabber** platforms. For XMPP, this includes the use of **XMPP Chatrooms** for group communication, which can be configured as either public or private. The university recommends the use of the **Pidgin** client for managing these chatrooms, noting specific technical constraints such as the prohibition of spaces in room names. It further provides detailed configuration guides for setting up XMPP clients, emphasizing the use of the `jabber.uni-greifswald.de` domain and the critical importance of **Certificate Fingerprint Verification** (using SHA1 and SHA256 hashes) to ensure secure, authenticated connections to the chat server. The wiki also documents the capability for **XMPP File Transfer**, specifically detailing the request-and-confirmation workflow used in the Pidgin client to send files between users. It further details the process of **XMPP Contact Management**, including manual addition using the university's specific address format, directory-based searching with a 30-entry limit, and the mandatory authorization request process to ensure mutual consent between chat partners.

Regarding the **Matrix** implementation, the URZ provides a decentralized chat platform that supports End-to-End Encryption (E2EE) as standard for 1:1 and group conversations, making it suitable for exchanging sensitive data. Access requires a prior consent declaration via the **UMS** and authentication via **Shibboleth**. The URZ recommends the **Element** client, specifically noting that **Element Classic** must be used on mobile devices to maintain Shibboleth compatibility, as **Element X** is currently unsupported for this purpose. The wiki now includes detailed onboarding instructions for Matrix, including the configuration of the home server at `matrix.uni-greifswald.de` and the assignment of a unique Matrix-ID (MXID). Recent additions detail the legal and privacy framework for Matrix, emphasizing GDPR compliance, the use of random IDs for anonymization, and the implications of federated data storage on data retention. It also emphasizes the critical importance of the **Matrix Recovery Key**, which users must generate and store securely (e.g., in **KeePassXC**) to prevent the permanent loss of encrypted message history across sessions.

The wiki also includes guidelines for **Encrypted Communication** via XMPP using the **Off The Record (OTR)** protocol. This ensures that users can achieve end-to-end encryption for their instant messaging, provided both parties use OTR-capable clients like **Pidgin** (Windows/Ubuntu) or **Adium** (macOS). The documentation details the necessity of private key generation and the bidirectional authentication process—via fingerprints, passphrases, or Q&A—to establish a "Private" and verified communication channel.

The wiki also documents the **Resource Management** (Ressourcenverwaltung) process, detailing how technical assets like IP addresses and web space are requested, approved, and extended via the **UMS**. This lifecycle now includes the process for **Resource Deletion**, which allows users to remove assets they no longer require through the same management interface used for extensions. It highlights a 12-week grace period for expired resources to prevent data loss and identifies the **Groupware** ticket system and a dedicated hotline as the primary support channels for these central Campus-IT services. This includes the management of **External Domains**, which are treated as special cases requiring approval from the Rectorate or Dean's office. The wiki further details the process of **Resource Responsibility Transfer**, explaining how to add new responsible persons or relinquish responsibility, and the critical impact of immediate access loss when removing oneself from a resource.

Most recently, the wiki has integrated documentation on **Shibboleth**, the central authentication and authorization service. This system enables a **Single-Sign-On (SSO)** experience, allowing users to access multiple services—including the **Universitätsbibliothek (UB)** licensed databases, **LSF**, and **Moodle**—using their central account. A key feature is the **Identity Card**, which provides transparency and user control over the data transmitted to service providers. The implementation of Shibboleth has significantly improved accessibility by removing the need for a VPN when accessing many university resources from external networks. The wiki now details the specific login workflow involving the **DFN-AAI** federation and the university's Identity Provider (IdP) server, emphasizing that credentials remain secure within the university's infrastructure. It also clarifies the distinction between the explicit consent model used for external services and the statutory-based processing for internal services, and identifies the specific `eduPerson` attributes used for automatic authorization.

Additionally, the URZ provides a set of miscellaneous services including **High Performance Computing**, **Multifunctional Smart Cards**, a system **Update Service**, and **Server Virtualization**. Support for these and other central Campus-IT services is streamlined through a **Groupware-based ticket system** and a dedicated support hotline (extension **1420**). The university's HPC capabilities are centered around the **HPC Brain-Cluster**, which provides advanced computational resources for research. This is further extended by **Apphub**, a browser-based portal that provides cloud-based programming environments (via JupyterLab, RStudio, and Code-Server) and virtual desktop systems for GUI-heavy software like SPSS, Stata, and 3D reconstruction tools. This allows students and staff to offload performance-intensive tasks to URZ high-performance hardware, ensuring accessibility across nearly all end-devices. The multifunctional chip card system has been expanded to include a payment function via the **Studentenwerk**, allowing users to maintain a digital credit purse (**Bezahlbörse**) for use in university cafeterias across Greifswald, Stralsund, and Neubrandenburg, while maintaining strict data privacy. It also integrates an electronic access control system (**eZKS**) that manages building entry via a combination of online and offline locks, requiring periodic card updates to maintain access. The **Update Service** ensures the security and currency of these systems, specifically through the **WSUS** (Windows Server Update Service) for Microsoft environments. WSUS is mandatory for devices in the **Vollservice** tier of the Device Management System, ensuring that critical patches for Windows 10, Windows Server, and Microsoft Office are deployed centrally, while allowing other domain-joined devices the option to bypass the internal server in favor of direct Microsoft updates.

The wiki has now been expanded to include the operational procedures for **Certificate Revocation**. This ensures that if a private key is compromised, users have clear paths to invalidate their certificates—either through a self-service portal (provided a revocation PIN was set) or via administrative support from the URZ.

The wiki has further expanded to cover **Central Data Storage** and **Backup Services**. The URZ provides a central file server that enables device-independent data access, ensuring that users can work from any end-device. This is supported by a **Central Backup Strategy** that allows for the rapid restoration of data in the event of loss. Furthermore, the URZ provides backup storage for decentralized servers, extending its data security infrastructure to non-centrally managed systems. This is currently implemented via a transition from the legacy **Tivilo Storage Manager (TSM)** to **Restic**. The URZ provides a dedicated **Restic Backup-Service** for server systems, which includes client-side encryption and automated daily backups via URZ-provided scripts for Linux and Windows. For Windows systems, this is achieved through a streamlined installation package containing PowerShell scripts and Restic binaries that automate repository initialization and scheduling via the **Windows Task Scheduler**. To manage storage resources, the university enforces a retention policy of **60 days** for deleted files and a maximum of **60 versions** per file, while offering long-term **Archiving** with no fixed expiration. Now, the wiki also documents the use of **FreeFileSync** and **RealTimeSync** to synchronize local working copies of data with the central file server, providing a method for users to work locally while maintaining server-side redundancy.

The wiki now also documents the mandatory security layer for the **Zentraler Nutzeraccount**, specifically the requirement for **Two-Factor Authentication (2FA)**. This is implemented using **TOTP** (Time-based One-Time Password), which must be activated via the **UMS** during the first login. The system supports both QR-code scanning (e.g., via **FreeOTP**) and manual secret entry (e.g., via **KeePassXC**), ensuring that users can secure their accounts using a variety of compatible software.

The wiki also now documents the process of **Account Exchange**, which allows users moving between the University and the University Medicine to transfer their existing user accounts to a new employment relationship. This process involves a specific dual-ticket verification workflow via Groupware to overcome data availability gaps regarding birth dates.

Finally, the wiki documents the **Account Deletion** lifecycle. This phased process ensures that users are notified of upcoming expirations and provided with a grace period (30 weeks for general users, 4 weeks for UMG staff) before their account is deactivated. A critical aspect of this process is the automatic removal of the user from the responsibility of all registered URZ resources upon deactivation, necessitating the transfer of resource ownership during the grace period. Permanent deletion occurs one year after the usage authorization expires.

The wiki also includes the legal and privacy framework for these accounts, detailing the role of the **Identity Management System** in automated provisioning and the specific legal grounds for account administration and username changes under the **GDPR**. It defines the **Karenzzeit** (grace period) for data retention and identifies the **E-Verwaltung** as a key processor for student and doctoral candidate data.

The wiki also has been expanded to include the **EasyDB** media database, a tool for tagging, organizing, and sharing media files. It details the distinction between **Pools** (exclusive storage) and **Mappen** (thematic groupings), as well as the use of **Dublin Core** metadata and automated mapping. The documentation also covers the sharing workflow for both internal university members and external parties via secure download links.

The wiki has further expanded to cover **Digital Teaching (Digitale Lehre)**, emphasizing a student-centric approach to e-learning. It documents the role of **Moodle** as the central hub for all digital teaching activities, where other tools for conferencing, streaming, and content delivery are integrated. The wiki provides pedagogical guidance on managing cognitive load through short information blocks and considers the technical and personal constraints of students, such as limited device access or care work obligations.

It further details the technical infrastructure for interactive and broadcast communication. This includes **Web Conferencing** tools like **BigBlueButton** (up to 100 participants), **Jitsi/Meet** (up to 35), and **DFNconf/Pexip** (up to 23), along with best practices for moderation in large digital sessions. For reaching very large audiences, the wiki documents **Livestreaming** via **DFNconf/Pexip**, noting the inherent signal latency and the necessity of a separate back-channel for interaction.

Additionally, the wiki covers the creation of asynchronous content through various **Video Recording Formats**, ranging from audio-only podcasts to complex multi-track recordings. These materials are hosted on the internal **GrypsTube** service and linked within Moodle. The wiki also outlines the technical and environmental requirements for instructors to ensure high-quality digital delivery, while clarifying that the URZ provides the software infrastructure but not the physical recording rooms or hardware.