Blogs

Product Talk

Ivan Chalif Senior Product Manager

Recently in Administration Category

Add a Read-Only linux user


Depending on how you have implemented StrongMail, it may make sense to create a limited access user account. This will allow you to setup processes that can harvest information from the StrongMail application log files.

Here's how to do it:

1.) Create the following group with the groupadd command.

$ groupadd -g 5000 smuser

2.) Use the useradd command to create the following user account in the home directory.

$ useradd -u 5000 -g 5000 -md /home/smuser -c "Strongmail Linux User " -s /bin/bash smuser

$ cat /etc/passwd
$ cat /etc/group

Review the changes you have made to these files, there should be lines at the bottom beginning with the string smuser.

3.) Assign initial passwords to both accounts. For user smuser assign the password of smuser (type smuser in at this point - lowercase no quotes)

$ passwd smuser
Changing password for smuser
New Password:
BAD PASSWORD: it is based upon a dictionary word

Retype New Password:
$

4.) Logout of the StrongMail system.

$ logout

5.) Test the account you have just created by logging in as user smuser with a password of smuser. IMPORTANT: Once you confirm that the user is functioning properly, change the password again to insure that it is secure.

6.) Repeat steps 2, 3, 4, 5 and 6 for each additional user account to be created. Note that linux expects the home directory name (/home/smuser1) to be identical with the username (smuser1), the last argument to the
useradd command.

7.) To allow read only access to the strongmail/log directory for read only access, the world permissions of Read/eXecute must be granted to both directories.

Existing Permissions for the directories strongmail and strongmail/log are:

Perms      Owner       Group       Name
drwxrwx--- strongmail strongmail strongmail
drwxrwx--- strongmail strongmail log

and should be changed to the following:

Perms       Owner       Group       Name
drwxrwxr-x strongmail strongmail strongmail
drwxrwxr-x strongmail strongmail log

$ cd /data1
$ chmod 775 strongmail
$ cd /data1/strongmail
$ chmod 775 log

Special thanks to Norm DeValliere for helping out with this post.
Posted by: Ivan Chalif at 7:28 AM
Categories: Administration , Logs , Platform

Roles in Message Studio

If your company has multiple staff members working on your email marketing programs, you are probably interested in learning more about Message Studio's role capabilities. Roles can streamline your work flow and insure that individuals working on your email only have access to the functions relevant to them. This is especially important for those companies that are governed by security processes or by compliance regulations.

In Message Studio, a role is a collection of permissions that is assigned to a user. A role belongs to a single organization, but is available across that organization’s sub-organizations.

Message Studio includes four pre-defined roles: Approver, Content Manager, Data Manager, and Mailing Manager, each with different permissions across the functional areas of the application.

role_sm.gifA description of each in included below.

  • Approver - An approver can edit, view, and approve message templates and mailings
  • Content Manager - A content manager can create, edit, delete, and view message templates, attachments, and content blocks
  • Data Manager - A data manager can create, edit, delete, and view internal data sources, external data sources, targets, suppression lists, and seed lists
  • Mailing Manager - The mailing manager has all permissions pertaining to a mailing

But those are not the only roles you can have. Message Studio allows you to create roles using any of the permissions that are available for each functional area. Below, you can see all of the different permissions that are available.

permissions_sm.gifYou can create roles specific to your business or based on the needs of different types of users. For security reasons, only super-users and administrators can create and edit roles, so you don't have to worry about unwanted roles popping up or existing roles changing beyond their intended scope.

Posted by: Ivan Chalif at 11:58 AM
Categories: Administration , Application