Deaddrop can be configured through both a web-based interface and a command-line environment, offering flexibility for different administrative preferences.
Web-Based Interface
The graphical interface requires the ddadm package to be installed (default). Once set up, it is accessible over TLS on port TCP/8443. This interface provides an intuitive way to manage the system through your web browser.
Command-Line Access
For direct control, administrators can interact with Deaddrop via the command line. This environment is typically accessible in one of two ways:
Locally: Through a console session on the system itself.
Remotely: Using the SSH network protocol to establish a secure connection.
Both methods provide full administrative access to configure and manage the system.
Deaddrop supports several methods of administrative access, allowing both local and remote management.
Administrators can access Deaddrop directly through the system console. This is typically available via:
Recommendation: Use individual user accounts and escalate privileges using sudo when administrative access is required. Note that sudo is configured to authenticate using the root password.
Deaddrop can be configured to allow secure remote access via the SSH (Secure Shell) protocol.
Recommendation: Just as with console access, it is best practice to log in using personal user accounts and switch to the root user using sudo. sudo is configured to require the root password for authentication.
For browser-based administration, Deaddrop provides an HTTPS interface once the ddadm package is installed. This interface is accessible over TLS on port 8443/TCP.
This option allows secure, remote configuration through a graphical user interface.
Deaddrop uses RPM packages for software management. Keeping the system up to date ensures stability, security, and access to the latest features.
Automatic updates is enabled by default since version 4.0.0
To automate the update process, you can install the ddplugin-upgrade package:
dnf install ddplugin-upgrade
Once installed, this plugin will manage updates in the background without requiring manual intervention.
To determine which version of Deaddrop is currently installed, run:
rpm -qa deaddrop
The output will follow the format:
[name]-[version]-[build_version].[platform].noarch
Example:
deaddrop-4.4.0-1749812404.fc41.noarch
Operating system kernel updates are treated as a special case. While the kernel can be updated like any other package, the changes only take effect after a system reboot.
To apply a newly installed kernel:
systemctl reboot
Note: Always ensure the system can safely reboot (e.g., services properly shut down, backups complete) before executing this command. Automatic upgrades will reboot system if needed.
Deaddrop supports multiple authentication mechanisms, with behavior depending on account type and system version.
Authentication Modes
As of Deaddrop version 3.2, the default authentication method for local, permanent, password-based accounts has changed:
Previously, Basic Authentication was the default for all password-based accounts. This behavior was standard up to version 3.1.
All local permanent password based accounts will use Session based authentication with an exception for users with the API-role which will use Basic Auth. Basic Auth was default for local password based accounts and was used for all accounts before deaddrop version 3.2. This has changes since version 3.2 to session based authentication. Accounts can manually be migrated to the new session based authentication. Administration account is still using Basic Auth.
Migrating to Session-Based Authentication
Accounts created prior to version 3.2 may still be using Basic Auth. These can be manually migrated to use the new session-based authentication model for improved security and modern session handling.
To create a new end-user account in Deaddrop, use the following administrative script:
/opt/sysctl/deaddrop/admscripts/add_account.pl
This script requires three arguments:
Example
/opt/sysctl/deaddrop/admscripts/add_account.pl example@sysctl.se 46123456789 perm
Important Notes
Deaddrop supports automatic account provisioning for users authenticated through x509 certificates or SAML, once the respective integrations have been properly configured.
Once x509 integration is in place, accounts are automatically created the first time an authorized user attempts to log in with their certificate.
Once SAML integration has been completed, accounts for authorized users are created automatically on first login via the SAML Identity Provider (IdP).
To remove an end-user account from the Deaddrop system, use the following administrative script:
/opt/sysctl/deaddrop/admscripts/removedeaddropuser.pl
This script takes a single argument:
Email address of the user to be removed (must be in lowercase)
Example
/opt/sysctl/deaddrop/admscripts/removedeaddropuser.pl example@sysctl.se
Notes:
If a user forgets their password, a new one can be generated and sent to them using the following administrative script:
/opt/sysctl/deaddrop/admscripts/reset_password.pl <email_address>
This script takes one argument:
Example
/opt/sysctl/deaddrop/admscripts/reset_password.pl example@sysctl.se
Notes
For accounts created prior to Deaddrop version 3.2, Basic Authentication may still be in use. To align with current security practices, these accounts can be migrated to Session-Based Authentication using the provided script.
Migration Script
/opt/sysctl/deaddrop/admscripts/convert_basic_auth_to_session_account.pl
This script takes one argument:
Example
/opt/sysctl/deaddrop/admscripts/convert_basic_auth_to_session_account.pl example@sysctl.se
Notes
Administrative accounts can be created directly through the Deaddrop web-based administration interface.
Steps to Add an Admin Account via the Web GUI
Default Administrative User: sysadm
During initial system installation, the system automatically generates a password for sysadm.
This generated password is stored in the following secure file:
/root/ddadm-sysadm-initial-password
Important:
This default password should be changed immediately after installation to comply with your organization’s password policy.
Administrative user accounts can be removed through the Deaddrop web-based administration interface.
Steps to Remove an Admin Account via the Web GUI
If you need to change the password for an administrative user in the web-based admin interface, you can do so using the htpasswd command.
Example Command To reset the password for an admin user named robert, run:
htpasswd -B -C6 /opt/sysctl/ddadm/etc/ddadm/.htpasswd robert
This command:
Default Administrative User
The default administrative username for the web GUI is:
sysadm
If no other users have been created, this is the primary account for system administration.
Notes
When a dispatch is created for a recipient—such as demo@sysctl.se — and that user does not have a permanent account, the system will automatically generate a temporary account for them.
Temporary Account Location
The temporary account is created in the following directory:
/var/deaddrop/html/demo@sysctl.se/
This directory serves as the root for that user’s Deaddrop session.
Uploaded Files
Any files uploaded to the dispatch are stored in a randomized subdirectory within the user’s temporary account folder. The full path typically looks like:
/var/deaddrop/html/demo@sysctl.se/<unique_id>/
For example:
/var/deaddrop/html/demo@sysctl.se/6ffe03aee5d7ccd78b3b22b6de8d660df141147f129ee806cac5711f7e411d9d
The *
Notes
Shared dispatch — especially those associated with temporary accounts — can be removed using an administrative script provided with the system.
Script Location
/opt/sysctl/deaddrop/admscripts/
To remove a specific shared dispatch, use the removedeaddropuser.pl script with the following syntax:
./removedeaddropuser.pl <email_address> <drop_directory_hash>
Example
[root@localhost ~]# ls /var/deaddrop/html/demo@sysctl.se/
6ffe03aee5d7ccd78b3b22b6de8d660df141147f129ee806cac5711f7e411d9d
[root@localhost ~]# cd /opt/sysctl/deaddrop/admscripts/
[root@localhost admscripts]# ./removedeaddropuser.pl demo@sysctl.se 6ffe03aee5d7ccd78b3b22b6de8d660df141147f129ee806cac5711f7e411d9d
Verifying Removal
To confirm that the account and all associated files have been deleted, attempt to list the user directory:
[root@localhost admscripts]# ls /var/deaddrop/html/demo@sysctl.se/
ls: cannot access /var/deaddrop/html/demo@sysctl.se/: No such file or directory
This error indicates that the directory (and its contents) no longer exists.
Note on Temporary Accounts
If the account was temporary and all its shared content has been deleted, the entire user directory (e.g., /var/deaddrop/html/demo@sysctl.se/) will also be automatically removed as part of the cleanup process.
Deaddrop’s system behavior and operational settings are primarily managed through configuration files. Most administrators will only need to modify a single file after the initial setup.
Main Configuration File
The primary configuration file for Deaddrop is:
/opt/sysctl/deaddrop/conf/admin.conf
This file contains key system settings that determine Deaddrop’s runtime behavior and environment-specific configurations.
Default Settings File
/opt/sysctl/deaddrop/conf/default/admin.conf
This file serves as the baseline and should not be modified directly. Instead, override values in the primary admin.conf file as needed.
Editing Configuration
Applying Changes
After making any configuration changes, you must restart the Deaddrop service for the changes to take effect:
systemctl restart deaddrop
Deaddrop configurations are stored in an .ini file and must follow the format:
key = value
Each configuration entry should consist of a key-value pair separated by an equals sign.
Default: avscan_plugin_enabled = 0
Description:
Enables antivirus scanning for files transferred via Deaddrop. When set to 1, all files will be scanned, and any infected files will be quarantined.
Note:
This feature requires the ddplugin-av plugin to be installed.
Default: avscan_script_file = /opt/sysctl/ddplugin-av/scripts/avscan.pl
Description:
Specifies the script responsible for triggering antivirus scans.
WARNING: Changing this will likely not work.
Default: emaildeaddropadmin = admin@domain.tld
Description:
Specifies the email address that Deaddrop will use as the sender when notifying the administrator.
Default: emaildeaddropservice = service@domain.tld
Description:
Defines the email address Deaddrop uses as the sender when sending notifications to user accounts.
Note:
This value supports the mailbox format, e.g., ‘Deaddrop Service service@domain.tld’.
Default: support_info_email = service@domain.tld
Description:
Specifies the email address displayed by Deaddrop for user support inquiries.
Default: support_info_number = 070123456789
Description:
Specifies the phone number that Deaddrop will display for user support contact.
Default: email_sender_is_system = 1
Description:
Determines which email address Deaddrop uses as the sender for outgoing messages.
Default: wwwroot = https://deaddrop.domain.tld
Description:
Defines the base URL that Deaddrop expects users to access the service from. This value is used when generating links in emails and other user-facing communications.
Default: passwordlength_min = 12
Description:
Specifies the minimum allowed length for user passwords.
Default: passwordlength_max = 250
Description:
Specifies the maximum allowed length for user passwords.
Default: passwordregex = A-Za-z0-9
Default: min_classes = 4
Description:
Specifies the minimum number of character classes required in a password. The supported character classes are:
A value of 4 enforces the use of all four character classes.
Default: post_max = 10240000000
Description:
Defines the maximum allowed size (in bytes) for HTTP POST data submitted to Deaddrop.
Default: smspasswordchars = AaBbCcDdEeFfGgHhJjKkMmNnOoPpQqRrSsTtUuVvWwXxYyZz123456789
Description:
Defines the character set used for generating temporary passwords sent via SMS. The password will be composed only of characters from this string.
Default: smspasswordlength = 8
Description:
Specifies the length of the temporary password sent to users via SMS.
Default: language = en
Description:
Specifies the default language used by Deaddrop.
Supported values are:
Note:
The language used in emails is determined based on the following evaluation order:
Default: timeout = 900
Description:
Specifies the number of seconds of user inactivity after which Deaddrop will automatically log the user out. A value of 900 corresponds to 15 minutes.
Default: Custom_Design = 0
Description:
Enables the use of a custom design/theme for the Deaddrop interface.
Default: Custom_Design_Brand = default
Description:
Specifies the directory name containing the custom design assets such as images, text, and CSS files.
Default: Global_Contacts_Enable = 0
Description:
Enables or disables the use of global contacts within Deaddrop.
Default: Local_Contacts_Enable = 1
Description:
Enables or disables the use of local (user-specific) contacts in Deaddrop.
Defaul: Allow_Share_dd = 1
Description:
Allows users to grant their contacts temporary access to use Deaddrop.
Default: use_mcs = 1
Description:
Controls whether Deaddrop assigns unique MCS (Multi-Category Security) labels to all users.
Default: send_password_insecure = 0
Description:
Controls whether passwords are sent via insecure channels.
Warning:
Setting this to 1 poses a significant security risk and should be avoided.
Default: first_run = false
Description:
Enables the “first run” view for users upon their initial login.
Default: change_password = false
Description:
Forces users to change their password upon their first login.
Default: hide_file_name_in_email = 1
Description:
Determines whether file names are included in email notifications.
Default: del_user_history_x_days = 0
Description:
Specifies the number of days after which a user’s personal history will be deleted.
Default: anon_sender_email =
Description:
If set, this email address will be used as the sender (consigner) for all outgoing emails, overriding the actual sender identity.
Default: force_email_lang = en
Description:
Forces all outgoing emails to use the specified language. Supported values:
Default: name_in_account_notify = 0
Description:
Controls whether the account name is included in the email notification sent after an account is created.
Default: ttl_max = 336
Description:
Specifies the maximum time-to-live (TTL) in hours for a Deaddrop dispatch. Can be exceeded via force_all_dispatch_ttl or force_grant_contact_temp_access_ttl.
A value of 336 corresponds to 14 days.
Default: ttl_default = 72
Description:
Specifies the default time-to-live (TTL) in hours for a Deaddrop dispatch. Users can modify this value when creating a dispatch, up to the maximum defined by ttl_max.
Default: = 0
Description:
Force time-to-live (TTL) to a fixed amount of hours for all Deaddrop dispatches. This renders users unable to modify TTL when creating a dispatch. Unaffected by ttl_max.
Default: = 0
Description:
Force time-to-live (TTL) to a fixed amount of hours for temporary deaddrop access grants. This renders users unable to modify TTL when granting a contact temporary deaddrop access. Maximum 336 and unaffected by ttl_max.
Default: password_enabled= 1
Description:
Enables or disables password-based authentication for Deaddrop.
Default: saml_enabled = 0
Description:
Enables or disables SAML (Security Assertion Markup Language) authentication in Deaddrop.
Default: client_cert_enabled = 0
Description:
Enables or disables the use of X.509 client certificates for authentication.
Default: dns_enabled = 1
Description:
Enables or disables DNS lookups for verifying email addresses in Deaddrop.
Default: user_notification_script = /opt/sysctl/deaddrop/scripts/mail.pl
Description:
Specifies the script or program used to send user notifications. By default, this points to an email-based notification script.
Default: show_dd_version = 1
Description:
Controls whether the current Deaddrop version is displayed to logged-in users under the Support view.
Default: upstream_repo_server = https://updates.sysctl.se
Description:
Specifies the URL of the upstream repository server used for updates and package retrieval.
Example: https://updates.sysctl.se
Default: upstream_repo_server_path = deaddrop
Description:
Specifies the subpath on the upstream repository server used for Deaddrop updates. For example, combined with the server URL, the full path would be:
https://updates.sysctl.se/deaddrop
Default: upstream_repo_username =
Description:
Specifies the username required to authenticate with the upstream repository server, if applicable.
Default: upstream_repo_password =
Description:
Specifies the password used to authenticate with the upstream repository server.
Default: upstream_repo_proxy =
Description:
Specifies the proxy server to use when connecting to the upstream repository.
Example format: http://1.2.3.4:3128
Default: upstream_repo_proxy_usr =
Description:
Specifies the username for authenticating with the configured upstream repository proxy, if required.
Default: upstream_repo_proxy_pwd =
Description:
Specifies the password for authenticating with the upstream repository proxy.
Deaddrop supports operation across multiple domain names, allowing the system to dynamically adjust URLs based on the recipient’s email domain. This is especially useful for organizations with multiple brands or divisions, or when supporting SSO (Single Sign-On) for specific domains.
Default Behavior
By default, Deaddrop uses the wwwroot setting defined in:
/opt/sysctl/deaddrop/conf/admin.conf
This default applies to all users unless overridden by domain-specific configuration.
Domain-Based URL Overrides
To customize the URL used for users from specific domains, Deaddrop can reference a domain-to-URL mapping file:
/opt/sysctl/deaddrop/conf/email_domain_mappings.json.example
/opt/sysctl/deaddrop/conf/email_domain_mappings.json
[
{"domain":"sysctl.se", "url":"https://deaddrop.sysctl.se"},
{"domain":"sysctl.com", "url":"https://deaddrop.sysctl.com"}
]
When a dispatch is sent, the system checks the recipient’s email address domain and rewrites the URL in the outgoing email to match the corresponding entry.
Typical Use Case
This feature is commonly used in environments where recipients authenticate via SSO that is bound to specific domains. It ensures the user receives a domain-specific URL that aligns with their login infrastructure.
Deaddrop supports a global contacts directory, which allows predefined users to be accessible across the platform. This can streamline file sharing and communication, especially in large or multi-user environments.
Step 1: Enable Global Contacts To enable this feature, open the configuration file:
/opt/sysctl/deaddrop/conf/admin.conf
Then add or modify the following line:
Global_Contacts_Enable = 1
Save and close the file. You must restart Deaddrop for the changes to take effect:
systemctl restart deaddrop
Step 2: Edit the Global Contacts File
Global contacts are defined in the following file:
/var/deaddrop/globalcontacts/contacts.json
Use a text editor to add or update entries:
vi /var/deaddrop/globalcontacts/contacts.json
Example: Adding Global Contacts
Here is a sample JSON structure containing two global contacts:
[
{
"email": "global_contact@sysctl.se",
"language": "en",
"number": "123456789",
"groups": [],
"nick": "global_contact"
},
{
"email": "global_user@sysctl.se",
"number": "123456780",
"language": "en",
"groups": [],
"nick": "global_user"
}
]
Important:
The file must contain valid JSON syntax. Invalid formatting will result in errors when loading the contacts.
Deaddrop uses a customizable notification script to alert users about account and file events, such as file uploads, reminders, and account status changes. This script is defined by the user_notification_script configuration setting.
Default Behavior
By default, the system uses an email to send notifications such as:
Custom Notification Script
You can replace the default mail notification mechanism by creating a custom script, provided it follows the required format and permissions.
Requirements
-rwxr-x---. root ddadm system_u:object_r:ddbackend_mail_exec_t:s0
Notification JSON Format
The Deaddrop backend calls the notification script with structured JSON input. Here’s an example:
{
"from": "sender@sysctl.se",
"to": "receiver@sysctl.se",
"lang": "sv",
"mail_type": "new_file_available"
}
Supported Languages
Deaddrop currently supports the following languages by default:
Supported mail_type Values
Extended Data for File Downloads
If the mail_type is new_file_available, the JSON input will also include:
Example:
{
"from": "sender@sysctl.se",
"to": "receiver@sysctl.se",
"lang": "en",
"mail_type": "new_file_available",
"download_dir": "a9a7aff2a9d58cc1f0ee007f9c2e257a5d15918bfe62625b09b6e783b2ba536e",
"jobcard": "/var/deaddrop/work/backend/fromcgi/sender@sysctl.seXw9vFynlx3datEBmzPXIq4xS"
}
job.json Contents
The jobcard directory contains job.json with additional delivery metadata, such as:
{
"sender": {
"email": "sender@sysctl.se",
"number": "4671234567",
"lang": "en",
"first_run": "false",
"accountType": "perm",
"change_passwd": "false",
"settings": {
"show_number": "true",
"show_email": "true",
"show_lang": "false",
"show_nick": "true"
}
},
"ttl": "8",
"receivers": [
{
"email": "receiver@sysctl.se",
"language": "en",
"number": "46712345678",
"name": "",
"groups": [],
"nick": "nickname"
}
],
"ddmessage": "You are allowed to share files delivered by the deaddrop service",
"create_time": 1677585663,
"deaddrop_type": "me"
}
Deaddrop’s SMS functionality is configured using the gateway.conf file. This file defines how SMS notifications—such as password delivery or access alerts—are routed through the system’s SMS gateway.
Editing the Configuration
To modify SMS gateway settings, use the built-in vi text editor:
vi /opt/sysctl/sms/conf/gateway.conf
This is the primary configuration file used to define SMS behavior.
Viewing Default Settings
To view the default settings (without modifying anything), run:
cat /opt/sysctl/sms/conf/default/gateway.conf
Note:
Best Practice
Deaddrop uses SMS to securely deliver passwords to users. It supports integration with a wide range of SMS solutions, including both local hardware and external network-based services.
Supported SMS Providers
Deaddrop comes with built-in support for the following SMS delivery options:
This flexibility allows organizations to choose a provider that aligns with their infrastructure, pricing model, and geographic delivery capabilities.
Local Modem Setup
To use a local modem for SMS:
Network SMS Services
For all network-based SMS providers:
Multi-Gateway Support
Deaddrop supports multiple configured SMS gateways. When sending an SMS:
This ensures improved reliability and delivery success rates across heterogeneous SMS infrastructures.
To verify that the SMS functionality is working correctly, Deaddrop includes a script that allows you to send a test SMS through the system’s internal queuing mechanism.
Test Command
Use the following script to send a test message:
/opt/sysctl/deaddrop/scripts/sendsms.pl YOUR-CELLPHONE-NUMBER-HERE test
Replace YOUR-CELLPHONE-NUMBER-HERE with the target phone number, including the country code (without a + sign).
How It Works
Example
/opt/sysctl/deaddrop/scripts/sendsms.pl 46701234567 test
This sends a simple “test” message to the phone number +46 701 234 567.
If SMS notifications are not functioning as expected, use the following steps to diagnose and resolve common issues with the Deaddrop SMS subsystem.
1. Send a Test SMS
Begin by using the test script to verify the basic functionality of the SMS setup:
/opt/sysctl/deaddrop/scripts/sendsms.pl YOUR-CELLPHONE-NUMBER-HERE test
This sends a test message through the internal SMS queue using the configured gateway(s). If this fails, proceed with the following steps.
2. Test the Modem (If Applicable)
If you are using a direct-attached modem (local SMS gateway), verify that it can send messages independently:
/opt/sysctl/sms/admin/testmodem.pl YOUR-CELLPHONE-NUMBER-HERE
Note: This command accepts only one argument — the recipient phone number. The script will automatically provide a short test message.
Example:
/opt/sysctl/sms/admin/testmodem.pl 46701234567
3. Check the SMS Queue
Deaddrop uses an internal queue for processing outgoing SMS messages. To verify that messages are being queued and processed:
ls -al /opt/sysctl/sms/work/
4. Restart the SMS Backend Service
To ensure the backend daemon responsible for sending SMS is running properly, restart the service:
systemctl restart ss
Deaddrop uses the Network Time Protocol (NTP) to ensure accurate time synchronization on the host system. This is essential for proper operation of time-sensitive features such as token expiration, file availability windows, and audit logging.
Configuration File
The time server configuration is stored in:
/opt/sysctl/deaddrop/etc/chrony/deaddrop.conf
Updating the Time Server
To configure a new NTP server:
vi /opt/sysctl/deaddrop/etc/chrony/deaddrop.conf
server time.sysctl.se
Apply the Changes
Restart the Deaddrop time synchronization service to apply the new settings:
systemctl restart deaddrop-chronyd
Prerequisites for NTP to Function Properly
To ensure successful time synchronization:
Deaddrop uses Postfix as its mail delivery agent. By default, the mail system is configured to use the variable $mydomain, which typically resolves correctly without modification. However, you may specify a custom mail relay if required by your environment.
Configuration File
The mail relay configuration is stored in:
/opt/sysctl/deaddrop/etc/postfix/main.ddadm.cf
Updating the Mail Relay Server
To define a new outbound relay server:
vi /opt/sysctl/deaddrop/etc/postfix/main.ddadm.cf
relayhost = relay.sysctl.se
Authentication can be implemented using the following approach
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/opt/sysctl/deaddrop/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_sasl_tls_security_options = noanonymous
smtp_tls_security_level = encrypt
relayhost = [mail.sysctl.se]:587
Create the credential file /opt/sysctl/deaddrop/etc/postfix/sasl_passwd with the following content
[mail.sysctl.se]:587 email@fqdn.se:random_password
Create the password database file with the following command
postmap /opt/sysctl/deaddrop/etc/postfix/sasl_passwd
Apply the Changes
Restart the mail service to activate the new relay settings:
systemctl restart deaddrop-postfix
Notes
Deaddrop relies on DNS to resolve domain names for email delivery, time synchronization, external API calls, and more. Therefore, it is essential that a valid DNS server is configured on the host system.
Configuration File
DNS settings are managed through NetworkManager connection profiles. You will need to edit the appropriate interface-specific configuration file, typically found in:
/etc/NetworkManager/system-connections/INTERFACE_NAME.nmconnection
Replace INTERFACE_NAME with the name of the active network interface (e.g., eth0, ens33, etc.).
Setting DNS Servers
To define custom DNS servers:
vi /etc/NetworkManager/system-connections/INTERFACE_NAME.nmconnection
[ipv4]
method=manual
DNS=8.8.8.8,8.8.4.4
You can use any preferred DNS servers (e.g., public, internal, or provider-specific).
Apply the Changes
After editing the configuration, restart NetworkManager or bring the interface down and up to apply changes:
nmcli connection reload
nmcli connection down INTERFACE_NAME && nmcli connection up INTERFACE_NAME
Additional Tips
Customize how logs are retained on disk.
Default: Daily
Description: Controls how often logs are rotated, provided that a log file hasn’t reached the maximum file size.
Default: 20 megabytes
Description: Sets the maximum size of an individual log file in megabytes. If the maximum size is reached, files are rotated and a new log file is created. This overrides the rotation frequency.
Default: 7
Description: Sets the number of log files kept on disk. When the number of files on disk reaches this value, the oldest log file is removed during rotation - whether triggered by frequency or maximum size.
Deaddrop includes built-in mechanisms for system and data backup, supporting both automated and manual approaches. This ensures recovery capability in case of data loss, corruption, or misconfiguration.
Snapshot Backups (Virtual Machines)
If Deaddrop is deployed as a virtual machine, it is recommended to use hypervisor-level snapshot backups. This approach captures the entire system state—including configuration, OS, and data—for quick restoration.
File-Based Backups
Deaddrop also supports file-level backups, which can be accessed in two primary ways:
Automated Backup Service
Deaddrop’s internal backup system runs nightly at 01:01:00 and performs the following:
Note: Ensure adequate disk space is available for storing backup archives, and consider offloading older backups to an external storage location or remote archive.
Deaddrop provides convenient access to system backups and configuration archives through both HTTPS and secure file transfer protocols. This allows administrators to retrieve and archive backup files for disaster recovery or offline analysis.
Accessing Backups via HTTPS
The latest backup and configuration files can be downloaded directly from the Deaddrop administrative API (TLS-secured) by visiting the following URLs:
https://FQDN:8443/v1/backup/backups/latest.tgz
https://FQDN:8443/v1/backup/backups/ddconf.tgz
Replace FQDN with the fully qualified domain name of your Deaddrop instance.
These URLs require authentication and appropriate user privileges to access.
Accessing Backups via SCP or SFTP
Alternatively, backups can be retrieved directly from the file system using scp, sftp, or any compatible secure transfer tool. The backup files are located at:
/var/deaddrop/work/backup/backups/latest.tgz
Latest configuration backup
/var/deaddrop/work/backup/backups/ddconf.tgz
Make sure the user has sufficient permissions to access these paths.
Deaddrop supports the use of a replica server as a failover or backup solution. When configured properly, the replica server can act as a live standby, receiving data from the primary system and preserving operational continuity in the event of a failure.
Enabling Replica Functionality
To use a replica server as a backup target:
Notes
Deaddrop provides a dedicated restoration process that allows administrators to restore system configuration and user accounts from previously saved backup files. This can be used for disaster recovery, testing, or migration to a new server.
Step 1: Copy Backup Files
Place the appropriate backup archives in the following target directories on the system:
/var/ddadm/slave/configurations/ddconf.tgz
/var/ddadm/slave/accounts/latest.tgz
Step 2: Run the Restore Script
Once the files are in place, initiate the restore by running the provided restoration script:
/opt/sysctl/ddadm/scripts/ddslave_restore.sh
Important Notes
To enable replication between a primary Deaddrop server and a replica (backup) server, both systems must be properly configured. The replica server synchronizes account and configuration data from the primary, allowing it to act as a failover or backup target.
The primary Deaddrop server must have a dedicated backup account created specifically for replication purposes. This account is used by the replica server to authenticate and retrieve data.
On the replica server, you must define the backup account credentials and the master server’s domain in the following file:
/opt/sysctl/ddadm/conf/ddadm.conf
Example configuration:
backup_username = 'username_for_backup_account'
backup_password = 'password_for_backup_account'
backup_server = 'server.domain.tld'
Ensure that the domain name is resolvable and reachable from the replica host.
To activate automatic account and configuration synchronization on the replica server, run the following commands:
systemctl enable slave.timer
systemctl start slave.timer
systemctl enable slave_restore.path
systemctl start slave_restore.path
These services manage periodic synchronization and the automatic application of restored data.
If the replica server is intended to take over as the new master server, follow these steps:
systemctl disable slave.timer
systemctl stop slave.timer
systemctl disable slave_restore.path
systemctl stop slave_restore.path
© Copyright sysctl Aktiebolag 2013-2025. All rights reserved