Size does Matter: When just one instance won't do!
"Once You Pop You Can't Stop" is an iconic tagline that has been used by several snack brands to promote their products. This catchy phrase refers to the irresistible feeling of craving that occurs after the first bite of a crispy and flavorful snack. In this same way, Znuny becomes an irreplaceable system in your organization. As this happens, more and more departments may decide they want to join the party. This is when you make the decision, integrate or segregate.
Size does Matter: When just one instance won't do!
In networking, the goal of network segmentation and segregation is to limit how much sensitive data, the amount of hosts and services which can be accessed, while still allowing an organization to function effectively. These measures require careful planning, strong enforcement, close monitoring and no possibility of circumvention to be successful. Using multi-tenancy to separate a system is similar to segregating a network.
One way to relate network segmentation and segregation, a commonly known task for an IT department, in a multi-tenant software, is to think of each tenant as a separate network segment that has limited access to the shared resources of the software. Shared resources may be the directory server, external data sources or other resources. The aim is to isolate each tenant’s data and configuration from other tenants. This can help improve the security, performance, and reliability of the multi-tenant software, and reduce backup time.
Here are the top three reasons why to segregate:
Security: Segregating a system into separate tenants can help improve security by limiting the impact of a security breach. If one tenant is compromised, the other tenants remain secure.
Scalability: Segregating a system into separate mandates can help improve scalability by allowing each mandates to scale independently. This can help ensure that the system remains performant even as the number of users or amount of data grows.
Customization: Segregating a system into separate tenants can help improve customization by allowing each tenant to have its own configuration and settings. This can help ensure that each user has an experience that is tailored to their needs.
Znuny is not currently multi-tenant capable, but it mustn't be. As a free and open-source solution which you can host on-premise, you can set up as many smaller instances as needed. Connect them via the generic interface for any processes which interface to other Znuny instances.
Here are a few technical solutions to everyday problems during setup.
Entity Data
With the console, there are many tools which you can use to quickly script a setup together. Here is a list of the relevant commands:
- Admin::CustomerCompany::Add - Add a customer company.
- Admin::CustomerUser::Add - Add a customer user.
- Admin::DynamicField::DefaultColumnsScreenConfig - Adds and removes dynamic fields to/from default column screen configurations.
- Admin::DynamicField::ScreenConfig - Adds and removes dynamic fields to/from screen configurations.
- Admin::Group::Add - Create a new group.
- Admin::Queue::Add - Create a new queue.
- Admin::Role::Add - Create a new role.
- Admin::Service::Add - Add new service.
- Admin::SystemAddress::Add - Add new system address.
- Admin::TicketType::Add - Add new ticket type.
- Admin::User::Add - Add a user.
- Admin::Group::CustomerLink - Connect a customer user to a group.
- Admin::Group::RoleLink - Connect a role to a group.
- Admin::Group::UserLink - Connect a user to a group.
- Admin::Role::UserLink - Connect a user to a role.
Using a modern day editor and the help of multi-cursor editing. It's quite easy to create a list of commands to run on the command line. Alternatively, you can script these commands.
Example Script (not for production use)
#!/bin/bash
# Function to process each row from the CSV and execute the command
function process_group {
groupname="$1"
comments="$2"
su - otrs -c "bin/otrs.Console.pl Admin::Group::Add --name $groupname --comment \"$comments\""
}
# Path to the CSV file
csv_file="/tmp/input.csv"
# Read the CSV file line by line
while IFS=, read -r groupname comments; do
process_group "$groupname" "$comments"
done < "$csv_file"
Dynamic Fields
For dynamic fields, there is an import function, which allows you to quickly import many fields at a time, you just need to modify the ObjectType and Config.
Example YAML File (not for production use)
---
DynamicFieldScreens:
MyField:
Ticket::Frentend::AgentTicketPhone###DynamicField: 0|1|2
Ticket::Frentend::AgentTicketFreeText###DynamicField: 0|1|2
MySecondField:
Ticket::Frentend::AgentTicketFreeText###DynamicField: 0|1|2
DynamicFields:
MyField:
Name: MyField
Label: Human Readable Label
ValidID: 1|2
ObjectType: Ticket|Article|Customer|CustomerCompany
FieldType: Text|TextArea|Dropdown|Mutiselect|Checkbox|Date|DateTime
Config:
DefaultValue: ''
MySecondField:
Name: MySecondField
Label: Human Readable Label
ValidID: 1|2
ObjectType: Ticket|Article|Customer|CustomerCompany
FieldType: Text|TextArea|Dropdown|Mutiselect|Checkbox|Date|DateTime
Config:
DefaultValue: ''
Dynamic Field Configuration Options
Each field type has special options, which can be used. These options are:
- Text
RegExList: - ErrorMessage: MESSAGE Value: EXPRESSION` Link: http://example.com/page LinkPreview: http://example.com/page?view=preview
- TextArea
Cols: '50' Rows: '50' RegExList: - ErrorMessage: MESSAGE Value: EXPRESSION`
- Date and DateTime
DateRestriction: DisableFutureDates|DisablePastDates DefaultValue: '222' Link: '' LinkPreview: '' YearsnFuture: '5' YearsInPast: '5' YearsPeriod: '0'
- Dropdown
DefaultValue: Key PossibleNone: '0' PossibleValues: Key: Value Key2: Value2 TranslatableValues: '0' TreeView: '0' Link: http://example.com/page LinkPreview: http://example.com/page?view=preview
- Multiselect
DefaultValue: - Key - Key2 PossibleNone: '1' PossibleValues: Key: Value Key2: Value2 TranslatableValues: '0' TreeView: '0'
System Configuration
Some default settings, can be the same in any system, or also scripted during setup. By creating a similar YAML file, you can upload standard settings to a new system.
Example file (not for production use)
---
Modified:
HTTPSForceRedirect:
EffectiveValue: '1'
Name: HTTPSForceRedirect
HttpType:
EffectiveValue: https
Name: HttpType
SecureMode:
EffectiveValue: '1'
Name: SecureMode
SendmailModule:
EffectiveValue: Kernel::System::Email::SMTPTLS
Name: SendmailModule
SendmailModule::AuthPassword:
EffectiveValue: SECRETPW
Name: SendmailModule::AuthPassword
SendmailModule::AuthUser:
EffectiveValue: support@example.com
Name: SendmailModule::AuthUser
SendmailModule::Host:
EffectiveValue: mail.example.com
Name: SendmailModule::Host
SendmailModule::Port:
EffectiveValue: '587'
Name: SendmailModule::Port
Command line
You can also use the console command for individual settings (requires a bit more knowledge).
Example (not for production use)
su - znuny -c "bin/znuny.Console.pl Admin::Config::Update \
--setting-name FQDN \
--source-path /tmp/fqdn.yml (for more complex setting)|--value znuny.example.com (for simple settings)
These are just a couple of examples, your mileage may vary, of the tricks of the trade, that can be used to speed the setup of a new system, making your infrastructure more dynamic. This also gives you the freedom to make settings based upon the use case for the system and avoid complicated role, group, and ACL setups. In one case you may want to have the FAQ module, and in another instance not. Adding the FAQ, or other Add-ons makes administration a tiny bit more complex, in the case where not all users need the module.