slashTools

Slashdata 1.0 documentation

slashData
Date: Sep 2006
Author: Jacco Loonstra
History: Now part of slashTools, http://members.home.nl/slashtools
 Initial version made for OSGroningen, www.osgroningen.nl
License: This is free software (BSD license).

Table of Contents

  1. Purpose of slashdata
    1. Author's note
    2. Benefits
    3. Warning before use
  2. Before you start using slashdata
    1. Naming conventions
    2. Assumptions
    3. Recommendations
      1. Apache documentroot for applications on production server
      2. Apache documentroot on project servers
  3. Testing slashdata
  4. Using slashdata
    1. Setting up
      1. Installation
      2. Filesystem
      3. User/group administration
    2. Configurable variables
      1. Setting default user/groups
      2. Setting default directory names
      3. Setting default permissions
    3. General slashdata commands
      1. show_info
      2. show_envs
      3. show_login
      4. self_check
    4. Using slashdata in a production server environment
      1. Adding user directories
      2. Removing user directories
      3. Adding department directories
      4. Removing department directories
      5. Checking production environment permissions
      6. Setting production environment permissions
      7. Migrating existing websites for use with slashdata
    5. Using slashdata in a development/test server environment
      1. Adding project directories
      2. Removing project directories
      3. Checking development/test environment permissions
      4. Setting development/test environment permissions
    6. Using slashdata on the commandline or as part of an automated process
    7. Extending slashdata usage
      1. Enabling the File::Find perl module
      2. Moving critical data and configuration files to slashdata
  5. Error messages and warnings
    1. Error messages
    2. Warnings
  6. Appendix
    1. Example /etc/profile
    2. Todo list
  7. Disclaimer

1. Purpose of slashdata

1.1. Author's note

First of all, don't be intimidated by the size of this document!
The use of slashdata is pretty straightforward and simple, but I wanted to provide you with the best possible documentation.

The reason for writing slashdata is that in my IT consultancy times I saw my clients struggle with -basically- housekeeping.
As in a typical organisation IT has high importance, but basic housekeeping has not (sad but true), I saw there was a need for simple, but powerful tools.
As I was without a job for a while, I volunteered for a temporary job to help OSGroningen to get on track.
After that short period slashData grew to what it is now, a full featured tool for Linux/Unix file system administration.

I hope you enjoy using slashdata, as it will help you save your free time from disappearing in endless nights, discovering at the end that some permissions were not set the right way.

As I'm not a typical programmer (I use Perl to build prototypes and just show an idea works) I guess a lot of the slashdata code could be written better or more efficient. One of my goals was to build software that can be read (and maybe modified) by others also. And, slashdata works for OSGroningen as intended.

Slashdata's purpose is to give Unix systems administrators a tool for standardizing the directory structure on Unix file servers.
This directory structure can have several environments: production, test or development, providing user and group space (personal, organisational and project), and application space (e.g. websites or databases).
Slashdata provides a systemwide (customizable) standard directory structure for production servers, and a different one for test and development servers.

As Linux is finding its way to fileservers more and more (as a stabler, faster, simpler and cheaper alternative), there is a need for tools that provide simple user, department and project setup, checking and general management functionality.
And as the *icrosoft environments continue to push hardware limits and costs, Linux can be used so you don't have to upgrade your current hardware and make some considerable savings (and be better off anyway).

Slashdata is an opensource Perl package for use on most Unix platforms, and provides a tool for mapping organisational structure to IT infrastructure on production/test/development servers. Basically it is a tool for mapping personal en group information on a directory structure, giving the possibility of quickly setting up, checking en setting permissions, and enabling easy management of user, department and project directories.

The slashdata package should be sufficient for small to medium sized organisations, where Linux/Unix systems are used on the server side, and all data can be written on a single /data filesystem (which ofcourse can be, or preferably is, a mirorred or RAID set).
Slashdata can be a supplement for the use of apache, and samba and/or nfs.
Furthermore, slashdata scales well. You could always add more servers and use slashdata on them too ;-)
When all used slashdata executable files are configured the same, you can have a consistent setup on all your servers.

The good use of slashdata includes thinking about organisation of documents.
One of the options of the slashdata package is to enforce the access rights of the chosen directory structure.
Also, the sysadmin(s) should decide which groups to make, which users to add to these groups, and which rights have to be set.
However, slashdata has default permissions that should fit allmost every organisation.

As in the need for storing data, in the typical organisation there is a need for accessing applications.
A lot of these applications (in a Unix environment) will be systemwide, so no storage is required in the slashdata directory structure. However, you could move (for instance) your databases physically to the /data directorytree (for instance /data/database).
And a developed apache website for internal use can benefit from the slashdata directory structure as well.

This tool is meant to be a valuable tool for the Linux/Unix system administrator to help make their job easier.
Keep in mind that administering 10 users is easy, but if you have to deal with hundreds of users, things become different, and you are forced to become more systematical in your approach.

A typical (slashdata default) implementation for an organisation on the central production server would be as follows:

/data drwxrwxr-x root:root # ($BASEDIR in slashdata script)
  /system drwxrwx--- root:root # root accessible directory ($SYSDIR in slashdata script)
  /archive drwxrwx--- root:root # for removed directories ($ARCHIVEDIR in slashdata script)
  /account drwxrwxr-x root:root # ($USERDIR in slashdata script)
    /user1 drwx------ user1:companyname # private directory of user1
    /user2 drwx------ user2:companyname # private directory of user2
    /user3 drwx------ user3:companyname # private directory of user3
  /department drwxrwxr-x root:root # ($DEPDIR in slashdata script)
    /staff drwxrws--- companyname:staff # for members of group staff (which is a Unix group)
    /sales drwxrws--- companyname:sales # for members of group sales (which is a Unix group)
    /companyname drwxrws--- companyname:companyname # for all companyname groupmembers (which is a Unix group)
    /beheer drwxrws--- companyname:beheer # for beheer groupmembers (which is a Unix group)
  /application drwxrwxr-x root:root # ($APPDIR in slashdata script, documentroot in Apache)
    /webapp1 drwxrwxr-x companyname:webapp1 # webapp1 (which is a Unix group)
      /web drwxrwxr-x companyname:webapp1 # webap1 web
        /conf drwxrwxr-x companyname:webapp1 # httpd conf file location
and for a development server:
/data drwxrwxr-x root:root # ($BASEDIR in slashdata script)
  /system drwxrwx--- root:root # root accessible directory ($SYSDIR in slashdata script)
  /archive drwxrwx--- root:root # for removed directories ($ARCHIVEDIR in slashdata script)
  /application drwxrwxr-x root:root # ($APPDIR in slashdata script, documentroot in Apache)
    /myproject-1.0-dev lrwxrwxrwx root:root # link to the web branch in myproject, 1.0, devel
  /devel drwxrwxr-x root:root # ($DEVDIR in slashdata script)
    /myproject drwxrwxr-x root:root # name of the project (is also a Unix group)
      /1.0 drwxrwxr-x root:root # version dir, home dir for the project members
        /source drwxrws--- companyname:myproject # the source of the project
        /document drwxrws--- companyname:myproject # documentation of the project branch
        /web drwxrwsr-x companyname:myproject # if it's a web project
          /conf drwxrwxr-x companyname:myproject # the apache conf file directory

1.2. Benefits

Some benefits of using slashdata:

1.3. Warning before use

2. Before you start using slashdata


As with using any other tool (or not using any tool and doing everything by hand) you have to think about the logical structure of your organisation. User groups, department groups, project groups etc. have to be present in your IT organisation in some kind of form, from the most basic (/etc/passwd, etc/group) to NIS or LDAP.
Slashdata assumes this organisation is done the right way, but will provide some basic checking functions (see "slashdata self_check").
Furthermore, it won't create a user or group directory when it's not administrated the slashdata way in /etc/group (and /etc/passwd), NIS or LDAP.

2.1. Naming conventions

To efficiently map the organisational data onto the IT infrastructure you need strict naming conventions.
If one would not use these, chaos would present itself; not being able to access certain directories, documents, projects etc.
The use of slashdata can enforce a lot of things, but is only as strong as the will of the sysadmin to follow these naming conventions.

2.2. Assumptions

You can (and are advised to) customize slashdata to fit your organisation and local situation.
Before using slashdata, you have to edit the $BASEGROUP, $BASEUSER and $ACTIVEUSERS variables, and setup your filesystem.
Ofcourse these groups and this user have to be made available in your user/group administration.
You can also customize the default names for the different standard directories.

hint: You can see the used variables and their values with "slashdata show_config".

User/group administration Filesystem Permissions/users Using slashdata with websites Permissions/ownership settings
Slashdata has the following 'rules' for setting permissins and ownerships:

2.3. Recommendations

2.3.1. Apache documentroot for application on production server

If you use Apache as your http server on your production machine it is advised to set the slashdata application branch (default /data/application) directory as your DocumentRoot in Apache. Refer to your Apache documentation on how to do that.

Developed and tested slashdata based projects have a 'web' directory which could be "distributed" to the /data/application directory.

An example on how to "distribute" a tested webapplication:
You have developed and tested a web application, which is in the test branch.
This example uses default settings for slashdata.

The projects name is 'enquete', its version is '1.0'. As it is a webproject, it has a 'web' subdirectory.
When everything went well, you are good to go, and you can now use the http link 'http://yourservername/enquente-1.0-prd' on your server to see the index page of your newly created website.

If you want to move an allready (non-slashdata) website to the slashdata tree, note the following:

2.3.2. Apache documentroot on project servers

When you add a web project on a project server, slashdata creates a symbolic link from the "web" branch of the project to the slashdata application directory.
This way the "distribution" of the finished web project to a slashdata enabled production server is garanteed, as the conf file doesn't have to change.

Note however, that when you create a project with the "web" option on your dev/tst server, slashdata will write a default index.html in the "web" branch, and will create a default Apache conf file in the "web/conf" directory also.

Apart from this, slashdata will also create a symbolic link to your application directory, so your developed and tested webapplications can be moved to the production environment without changing the contents of the conf file (as an extra, if your Apache environment has a /etc/apache2/sites-available and /etc/apache2/sites-enabled directory, it will also create a link from the project conf file to the /etc/apache2/sites-available directory and from there to the /etc/apache2/sites-enabled directory. This way, on a newly created project, you only have to restart your Apache software and you are ready).

The advantage of this is that you have one DocumentRoot, but the developers are still able to change the contents of webpages and the conf file, without having access to other projects.
(Ofcourse, if you want to have strict naming conventions, you have to change the name of the conf file to "name-version-prd.conf", and make your symbolic links to /etc/apache2/sites-...).

3. Testing slashdata


I strongly advice you to test slashdata before you use it in your production or project environment.
Not only for checking it against your operating environment, but also to get to know its possibilities.
Use (copy and paste) the following script to setup a basic user/group environment to check slashdata.

Note:
#!/bin/bash
#
# script for testing slashdata, with local /etc/passwd + /etc/group
# your user/group tools could be different!

BASEUSER=companyname
BASEGROUP=companyname
ACTIVEUSERS=activeusers

groupadd $BASEGROUP
groupadd $ACTIVEUSERS
groupadd staff
groupadd sales
groupadd standardproject
groupadd webproject

# note that every user has $BASEGROUP as primary group
# note that $BASEUSER is a member of every group

useradd -g $BASEGROUP -G $BASEGROUP,$ACTIVEUSERS,staff,sales,webproject,standardproject $BASEUSER
useradd -g $BASEGROUP -G $BASEGROUP,$ACTIVEUSERS,staff staffuser
useradd -g $BASEGROUP -G $BASEGROUP,$ACTIVEUSERS,sales salesuser
useradd -g $BASEGROUP -G $BASEGROUP,$ACTIVEUSERS,webproject,standardproject develuser
After running this script (or entering the commands manually) you have done the basic user/group administration.
Now, you can start testing slashdata (don't forget to edit slashdata to match this testsituation).
Slashdata will give you hints if possible, if you made an error or something isn't right.
If slashdata complains about something, check what it says and correct it.

First check if slashdata has all its dependancies met:

  ./slashdata self_check

Now create the basic prd environment:

  ./slashdata setup prd

As we are testing, we will create the dev and tst environments also on the same machine:
Note that this is not recommended!

  ./slashdata setup dev
  ./slashdata setup tst

Let's create some user directories:

  ./slashdata add_userdir staffuser
  ./slashdata add_userdir salesuser
  ./slashdata add_userdir develuser

... the department directories:

  ./slashdata add_depdir staff
  ./slashdata add_depdir sales

... and some projects, one (dev) with and one (tst) without web branch:

  ./slashdata add_prjdir dev webproject 1.0 web
  ./slashdata add_prjdir tst standardproject 1.0

After doing all this, take a look in the /data directory and see for yourself what these simple commands did.
Change some permissions, manually remove a userdirectory and make a file (not a directory) with the same name.
And make a fake user- or department directory.
If you have Apache 2 installed, you can set the DocumentRoot to /data/application, and browse to your machine.

After that, run 'slashdata env_check tst' or 'slashdata env_check dev' and see what it says (you can also omit the prd/tst/dev parameter, but slashdata might take a lot longer to complete, then). Now you can run 'slashdata env_set' to correct the problems that slashdata can correct for you.

Now, to remove a userdirectory, try 'slashdata remove_userdir staffuser'
... and remove a department directory by 'slashdata remove_depdir staff'
... and remove a projectdirecory by 'slashdata remove_prjdir dev webproject 1.0'

After this, check the /data/archive directory for the removed directories.

As you can see it's really been made easy to do all these administrative actions.

To remove the test data from this test, just do a:

  rm -rf /data/account /data/department /data/application /data/archive /data/system /data/test /data/devel

and to remove the testgroups and testusers:

export BASEUSER=companyname
export BASEGROUP=companyname
export ACTIVEUSERS=activeusers

  userdel develuser
  userdel salesuser
  userdel staffuser
  userdel $BASEUSER

  groupdel webproject
  groupdel standardproject
  groupdel sales
  groupdel staff
  groupdel $ACTIVEUSERS
  groupdel $BASEGROUP

When you're convinced, you are now ready to install and start using slashdata.

4. Using slashdata


How slashdata does its job best is explained in this chapter.
Getting information about your organisation, configurings users/groups, configuring slashdata, and finally installing and using Slashdata in different environments.

4.1. Setting up

4.1.1. Installation

To be compatible with as much Unix or compatible systems as possible, slashdata comes as a slashdata-1.0-prd.tar.gz file. Eventually I'll add Debian and RPM also.
Download it, run tar xzvf slashdata-1.0-prd.tar.gz, and you will find a direcory containing this documentation file and the slashdata Perl executable.
That's all there is, nice and simple.
Note: A good place for the slashdata executable would be in /usr/bin/, permissions rwxr-xr-x, owned by root:root (the 'set_env' option will correct it if not set the right way), a good place for the HTML file would be /usr/share/doc/slashdata/slashdata-1.0-doc.html.

4.1.2. Filesystem

For slashdata to be used to the full maximum, you need to create a separate filesystem for it.
If possible, look for a filesystem tool that provides journalling options, like EXT3 or REISERFS on Linux.
The LVM based filesystems have these options too.
If possible, try to run this filesystem on a hardware RAID5- or mirrorred set of disks.
Note that it's not that important for slashdata, but think about how important your data is to you!

Slashdata can be installed and used normally on a / (root) filesystem (so just a directory /data), but this is only meant for testing purposes.

Slashdata is a serverside tool.
This means that a user directory "/data/account/exampleuser" on the production server can be NFS mapped to "/home/exampleuser" on the workstation.
This also means it can be mapped to "\\server\exampleuser" if using Samba in a *icrosoft environment.
The same applies for department directories. You could choose to make the /data/account and /data/department directories available for all users.
Because of the user and group permissions, the user kan only get access to those directories and documents that he is allowed to.

Note that on most group directories the sticky bit on the group is set.
This garantees that every file or directory created inside that directory is accessable to the group members.
Apart from this, when File::Find is installed, it will set all group rights to the owner rights to enforce the same thing for all files in that directory.

4.1.3. User/group administration

First you might want to make a schema of your organisation to do this step the right way.
Write down which departments are there, and which users are a member of which department.

After that make a list of which projects are there, and which status (dev or tst) they have.
Ofcourse you have to know also who is a member of which project.
Keep in mind, that slashdata doesn't differentiate between tst project users or dev project users if the project name is the same.
Just make all of them a member of this one project group, that's OK, users who are testing an application typically communicate a lot to users that are developing the same project.

You can now start making users and groups with the appropriate tools.
These can be tools that only work with local users and groups (/etc/passwd and /etc/group) but also network based tools like LDAP or NIS.
In a *icrosoft environment you probably need Active Directory for this.
Configuration of users/groups within these tools are considered out of scope for this document.

Slashdata will create one default department directory: the one with the name of your organisation, set in the $BASEGROUP variable.
Only if it exists as a Unix group, ofcourse, otherwise it will complain and exit.
Take care of the fact that every user, be it a real user or a logical user, has this group as its primary group.

For your conveniance, slashdata will also check if a user is part of the activeuser group.
If a user is not part of this group, for example because he takes a sabaticle, it will not be possible to make a user directory for that user, and the env_check and env_set commands will inform you if such a directory is present and can be removed.

4.2. Configurable variables

Slashdata can be configured to your needs, and this can be done in two ways.
The default values can be seen by using slashdata show_config.

4.2.1. Setting default user/groups

Edit the slashdata script and change the $BASEUSER and $BASEGROUP variables from companyname to the name of your organisation.
Ofcourse, don't use spaces as this name is going to be a Unix group.
Make this user and this group available with your user/group tools.
Furthermore, the $ACTIVEUSERS variable contains the value activeusers which is a good default name.
Also make this group available with your user/group tools.
Now you can make new users (or use existing users), and make new department and project groups and assign the users to them.

4.2.2. Setting default directory names

By editting the variables you can also change the names that slashdata will use for the different directories.
For instance, you could change everything to three letter names (dev,tst,app,sys etc.).
Be aware though that if you change the default to something else on one server, it is wise to do so on another server as well.

4.2.3. Setting default permissions

There is also the possibility to alter the default permissions and ownership of the slashdata directories.
You are advised not to alter them, as the default settings work great.
If you have a suggestion on changing the default permissions, please let me know.
###

4.3. General slashdata commands

4.3.1. show_info

4.3.2. show_envs

4.3.3. show_login

4.3.4. self_check
###

4.4. Using slashdata in a production server environment

You can use every slashdata command on the commandline.
For the following commands the prd environment is required.
If not available yet, create it with slashdata setup prd

4.4.1. Adding user directories

Before adding a user directory, check if the user is valid by using the standard Unix command groups with the username as an argument.
It will tell you if the user is valid and which groups the user is in.
After that you can use slashdata to add the userspace.
If NFS or Samba is configured, the user should be able to login now.
Ofcourse you can move existing user files to the just created directory also.

Syntax:

    slashdata add_userdir "name of user"

4.4.2. Removing user directories

If you want to remove a user directory, use slashdata remove_userdir name of user.
This command will move the user directory to the archive directory, so the system adminisitrator can do his thing with the data, whatever procedure your organisation has for this.

Syntax:

    slashdata remove_userdir "name of user"

4.4.3. Adding department directories

Before adding a department directory, add it to your Unix environment with the appropriate tool.
After that assign users to it, and add the department directory.
Syntax:

    slashdata add_depdir "name of department"

4.4.4. Removing department directories

Like the userdirectory above the directory will be moved to the archive.

Syntax:

    slashdata remove_depdir "name of department"

4.4.5. Checking production environment permissions

After migrating existing data to the slashdata environment it is nice to have a tool that only checks for the things that are not right yet.
It's quite logical to assume that the permissions and ownerships can be set wrong after migration.
Use this command to check these,and see if there are warnings.
Note that without (which is default) the File::Find Perl package, slashdata will not descent into the directories, it will only check the directories slashdata has made itself.
Also note that you can use slashdata env_check without a environment option to check all that is present.

Syntax:

    slashdata env_check prd

4.4.6. Setting production environment permissions

After checking with the above command, set everything straight with the slashdata env_set prd command.
If the File::Find Perl package works for you and is enabled, this command can be set in the nightly crontab to make you sleep better, and save you a lot of incidents.

Syntax:

    slashdata env_set prd

4.4.7. Migrating existing websites for use with slashdata

###

4.5. Using slashdata in a development/test server environment

You can use every slashdata command on the commandline.
For the following commands the dev or tst environment is required.
If not available yet, create it with slashdata setup dev and/or slashdata setup dev.

4.5.1. Adding project directories

Adding a project is plain and simple, like the above commands.
If you use the "web" option, you will get three extra's for free:
Note that if your distribution does not support the two created links, you have to make sure that Apache sources the newly created conf file while starting up.
Please check your Apache documentation on how to do this for your specific distribution.

Syntax:

    slashdata add_prjdir "tst"|"dev" projectname projectversion ["web"]

4.5.2. Removing project directories

Use this command for moving the project version to archive space.

Syntax:

    slashdata remove_prjdir "tst"|"dev" projectname projectversion

4.5.3. Checking development/test environment permissions

For checking permissions and ownership in the dev and tst environment, use the same command as in production environments.

Syntax:

    slashdata env_check dev
or:
    slashdata env_check tst

4.5.4. Setting development/test environment permissions

For setting things straight in project space.
Note that this command and the env_check command won't touch any data inside the web branches!
This is because slashdata can't know for sure about the permissions on these files and directories (sometimes directories need a rwxrwxrwx permission etc.).
Note also, that slashdata will check symbolic links also, but can't know if current links are correct.
Web project sites created with slashdata will not have such a problem, but if you create sites manually (why would you?) or if you migrated one, you may see this problem.

Syntax:

    slashdata env_set dev
or:
    slashdata env_set tst
or:
    slashdata env_set (to set permissions in all installed environments)

4.6. Using slashdata on the commandline or as part of an automated process

Slashdata has been created to provide as little messages as possible.
In a typical production environment, the sysadmins get lots of mail, and typically only want to know if something went wrong.
So, if slashdata creates a directory or sets rights ('slashdata env_set prd') it will say nothing, but other commands like 'slashdata env_check prd' which are typically run from the commandline will give all information.

All slashdata commands can be given from the commandline.
But you can automate the use of slashdata:
For info on installed (slashdata) applications, use the slashdata show_envs command.

4.7. Extending slashdata usage

Slashdata has been prepared for extension with the File::Find Perl module.
Default it is not enabled, because it requires Perl 5.006, and a lot of systems still run on 5.004.
If the File::Find module is enabled, slashdata can also recurse into directories and set ownership there.
A special note for Samba administrators: slashdata doesn't have any known problems with filenames with spaces or special characters.

4.7.1. Enabling the File::Find perl module

As of Perl 5.7 the File::Find package is integrated in the Perl distribution.
Because this module enables slashdata to recursively enter directorytrees and set permissions there, it's use is greatly recommended.
If you have a Perl version < 5.7, you have to get the File::Find package yourself.

You can download the File::Find package by entering the URL http://search.cpan.org/search?module=File::Find in your webbrowser.

NOTE: At the time of writing this document, File::Find has moved to the Perl 5.8.7/5.8.8 distribution and is not downloadable as a CPAN Perl package anymore.
In Ubuntu (and probably Debian) distributions it's available in the 'perl-modules' package.
You can however, go to the source page, and download the Find.pm code and put it in your Perl tree manually.
This can be a pain, but eventually you'll get there.

Most recent and updated Linux systems have the File::Find module in their Perl distribution.

To enable (or test the presence of) the File::Find module, open the slashdata script in an editor and:

    1. set the $FileFindInstalled variable to 1
    2. uncomment the line which says Perl to use the File::Find module

Save your file, and exit your editor.
If present, slashdata will now be able to recurse into directories, and set permissions there also.
If not present, you'll get an error and slashdata will exit.

4.7.2. Moving critical data and configuration files to slashdata

As having everything on one filesystem has its advantages for backing up, you could consider moving your web, database, mail and other organisation-critical data to /data also.

Note however that this is considered advanced system administration, so be sure you know what you're doing!

I'll give an example of how I did it for the PostgreSQL database software on my server:

Location of database files: /var/lib/postgresql
Location of configuration files: /etc/postgresql and /etc/postgresql-common
The software I use for moving the data is the great Midnight Commander tool, also open source and available in almost all distributions.

Ofcourse you can repeat this process for every service you consider critical (DNS, Apache, MySQL/PostgreSQL, LDAP, mail, etc.).
Before backing up shut down your databases, and afterwards start them up again.

5. Error messages and warnings


When you enter a slashdata command without providing the correct parameters, slashdata will give you specific help on that command.
If you use slashdata without commands, general help will be shown.
But as in any piece of software there is allways the possibility of bugs.
Or simply the possibility of you making a logical error ;-)
Much effort has been taken to pick them up and convert these to error messages or warnings.

5.1. Error messages

The following error messages you will probably never see if slashdata is used as intended.
Maybe the ones that are related to making a logical error in day to day work.
As slashdata checks a lot of things (even if you changed a directory to a file or symlink) there are a lot of errors possible.

Simple errors
User/group related
Filesystem related:
Serious errors (please let me know)

5.2. Warnings

While these warnings won't stop slashdata working, you are advised to check them out.
With most distributions and using slashdata as intended, you will never see these warnings.
Only exception is the use of the "env_check" option, which is ofcourse intended to give warnings.

6. Appendix

6.1. Example /etc/profile

The following is an example of (Bash) shell code you could add to your /etc/profile on development servers.
Users that are not a member of one of the installed projects are not allowed to login via a shell.
Project members of 1 or more projects can choose via a menu.

  if [ "`id -u`" -ne 0 ]; then
    HISTFILE=/tmp/$USER.bash_history
    MENUOPTIONS=`/usr/bin/slashdata show_login`
    clear
    if [ "$MENUOPTIONS" = "" ]; then
      echo You are not a member of one of the projects on this machine.
      echo Logging you off...
      echo ""
      exit
    else
      echo Welcome, $USER
      echo ""
      echo "Choose one of the following projects to login to:"
      echo ""
      Done=0
      select opt in $MENUOPTIONS; do
        for pd in $MENUOPTIONS; do
          if [ "$opt" = "$pd" ]; then
            Done=1
            break
          fi
        done
        if [ $Done -eq 1 ]; then
          break
        fi
      done
# set up user environment
      echo "$opt"
      ENVTYPE=`echo $opt | awk 'BEGIN {FS="_"} { print $2 }'`
      ENVNAME=`echo $opt | awk 'BEGIN {FS="_"} { print $1 }'`
      export HOME=/data/${ENVTYPE}/${ENVNAME}
      umask 000
      cd ~
      clear
      echo You are logged in on project \"$ENVNAME\".
      echo Your homedirectory is now $HOME.
      echo ""
    fi
  fi

6.2. Todo list


7. Disclaimer


This software is for use on Unix and compatible system with a Perl interpreter (version >= 5.004) installed.
It might work on other (earlier) Perl versions if you edit the script code, but you're on your own there.
I have made every effort possible to ensure that the software works as intended, but, as my resources are limited I could not test the software on every available Linux distribution or Unix compatible system.
I cannot garantee the flawless operation of this software, if it doesn't work as intended in your environment, please let me know!

In any case, I strongly recommend you to test the software before using it, as this makes common sense.

By downloading and/or using this software you agree to the following:

BSD License

Copyright (c) 2006, Jacco Loonstra
All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

  * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
  * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
  * My name may not be used to endorse or promote products derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDER "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
If you don't agree, then don't use this software!

This being said, please let me know what you think of this software!
When it runs on your system, and you are happy with it, please let me know.
If it doesn't run, or you have requests, please let me know too.
I might be able to fix or add it in a future release.

Mail regarding the use of slashdata can be sent to: 'slashtools @ users.sourceforge.net'
(please remove spaces in mailaddress)