Articles with tag 'Windows'

What is a Cross-Platform Link-Based Directory Structure?

A link-based directory structure is created completely using links so that both UNIX and WINDOWS systems can easily access files in a similar manner. Using this method, you can easily maintain tools to automatically create directories and files in a consistent nature. You also gain the ablility to move directories and/or entire projects to new physical file systems while being totally invisible to the users.

What is needed to create a Cross-Platform Link-Based Directory Structure?

Nothing is required to be purchased. All you need is a UNIX server running SAMBA with MSDFS configured.

How to set-up a Cross-Platform Link-Based Directory Structure

First we choose a common drive letter to mount under WINDOWS (in our examples we will choose N:). Similarly, for mounting drives under UNIX, we select the same name as automount drive (/n). By choosing the same path, users will be able to navigate on either WINDOWS or UNIX by using the same standard paths. This also allows conversion mapping when files needs to be moved between WINDOWS and UNIX easily.

example smb.conf

[global]
netbios name = LINKSERVER
workgroup = YOUR_DOMAIN
host msdfs = yes
security = ads (or whatever you use)
encrypt passwords = Yes
password server = YOUR_DOMAIN_CONTROLLER (or password server)
max log size = 5000
log file = /opt/samba/var/log/%m
use sendfile = no
local master = yes
os level = 3
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
log level = 3
log file = /opt/samba/var/log/%m
utmp = yes
utmp directory = /var/log/utmp
wtmp directory = /var/log/utmp
server string = DFS Server
guest ok = yes
[windows_n]
comment = Windows N: drive
path = /export/windows_n
msdfs root = yes
writeable = Yes
create mask = 0774
directory mask = 0775
guest ok = yes

example exports

/export/unix_n *(rw,no_root_squash,sync)

So on WINDOWS we would mount the SAMBA server LINKSERVERwindows_n as N: and on UNIX we would mount linkserver:/ /export/unix_n as /n

Creating a project under the Cross-Platform Link-Based Directory Structure

For this example lets create two projects (PROJECT1 and PROJECT2) with a simple directory structure: Remember that WINDOWS and UNIX both see different links, so we need to create the real directories on the filers the files will actually be located as well as two sets of links (one for WINDOWS and one for UNIX).

On the LINKSERVER you have two directorues /export/windows_n for WINDOWS links and /export/unix_n for UNIX links.

Create default project directories

mkdir /export/windows_n/projects
chmod 555 /export/windows_n/projects (So WINDOWS users can't create files at this level - otherwise won't be seen in UNIX)

mkdir /exportt/unix_n/projects
chmod 555 /export/unix_n/projects (So UNIX users can't create files at this level - otherwise won't be seen in WINDOWS)

Note: A physical projects directory doesn't need to be created this is just a fake level.

Create project directories

On your storage create real directories (At this point lets pretend we have only 1 storage filer called STORAGE1), this should be mounted under UNIX under /n if you use automounts. For this example we only have 3 top level directories to make the examples easier, in your studio, you can break down the levels as much as you need to. The more breakdown the better if you are forced to move data a later period of the project due to space constraints. One thing to consider is that users will not be able to create files are directories at the top level, so make sure you create ALL the top level directories that you are going to use.  The reason for this is simple, since the directories are actually links, WINDOWS users and UNIX users will not be looking at the same top level so one or the other will not be able to see what is created at that level.

Directories where files will actually be located:

mkdir /n/STORAGE1/PROJECT1

mkdir /n/STORAGE1/PROJECT1/Work
mkdir /n/STORAGE1/PROJECT1/Render
mkdir /n/STORAGE1/PROJECT1/Comp

mkdir /n/STORAGE1/PROJECT2

mkdir /n/STORAGE1/PROJECT2/Work
mkdir /n/STORAGE1/PROJECT2/Render
mkdir /n/STORAGE1/PROJECT2/Comp

WINDOWS Links: (no files ever located here) (pay attention to the double backslashes)

mkdir /export/windows_n/PROJECT1
chmod 555 /export/windows_n/PROJECT1 (So WINDOWS users can't create files at this level - otherwise won't be seen in UNIX)

cd /export/windows_n/PROJECT1
ln -s msdfs:STORAGE1PROJECT1Work Work
ln -s msdfs:STORAGE1PROJECT1Render Render
ln -s msdfs:STORAGE1PROJECT1Comp Comp

mkdir /export/windows_n/PROJECT2
chmod 555 /export/windows_n/PROJECT2 (So WINDOWS users can't create files at this level - otherwise won't be seen in UNIX)

cd /export/windows_n/PROJECT2
ln -s msdfs:STORAGE1PROJECT2Work Work
ln -s msdfs:STORAGE1PROJECT2Render Render
ln -s msdfs:STORAGE1PROJECT2Comp Comp

UNIX Links: (no files ever located here)

mkdir /export/unix_n/PROJECT1
chmod 555 /export/unix_n/PROJECT1 (So UNIX users can't create files at this level - otherwise won't be seen in WINDOWS)

cd /export/unix_n/PROJECT1
ln -s /n/STORAGE1/PROJECT1/Work Work
ln -s /n/STORAGE1/PROJECT1/Render Render
ln -s /n/STORAGE1/PROJECT1/Comp Comp

mkdir /export/unix_n/PROJECT2
chmod 555 /export/unix_n/PROJECT2 (So UNIX users can't create files at this level - otherwise won't be seen in WINDOWS)

cd /export/unix_n/PROJECT2
ln -s /n/STORAGE1/PROJECT2/Work Work
ln -s /n/STORAGE1/PROJECT2/Render Render
ln -s /n/STORAGE1/PROJECT2/Comp Comp

That's all you need to get started. In WINDOWS if you can navigate to N:projects and see two projects, where as in UNIX you can navigate /n/projects and see the same directories.

Moving Your Data

Now that your projects are created in the Cross-Platform Link-Based Directory Structure you are able to move your data whenever you like and be total invisible to the users.

Above we created two projects (PROJECT1 and PROJECT2) on our single storage filer STORAGE1. Well, the projects are getting two big and STORAGE1 is running out of room, we need to move the data.

In this example, let's say we have a second storage filer available (STORAGE2).

You do have some decisions to make, do you want to move an entire project to the new filer or do you want to move data from both projects? Either way you are covered.

Let's say we decided to move just "Render" and "Comp" directories for all projects to the new storage and keep the "Work" directories where they are.

No matther what your choice is, you will have to sync the data to the new storage filer and make sure the directories are set up the same as the original.

Note: Don't touch the links until the sync in complete! Also, you will need to take the directories down for a bit to do a final sync and make sure you don't lose any data!

Updating Windows LInks:

cd /export/windows_n/PROJECT1
rm -Rf Render
ln -s msdfs:STORAGE2PROJECT1Render Render
rm -Rf Comp
ln -s msdfs:STORAGE2PROJECT1Comp Comp

cd /export/windows_n/PROJECT2
rm -Rf Render
ln -s msdfs:STORAGE2PROJECT2Render Render
rm -Rf Comp
ln -s msdfs:STORAGE2PROJECT2Comp Comp

Updating UNIX Links:

cd /export/unix_n/PROJECT1
rm -Rf Render
ln -s /n/STORAGE2/PROJECTS1/Render Render
rm -Rf Comp
ln -s /n/STORAGE2/PROJECTS1/Comp Comp

cd /export/unix_n/PROJECT2
rm -Rf Render
ln -s /n/STORAGE2/PROJECTS2/Render Render
rm -Rf Comp
ln -s /n/STORAGE2/PROJECTS2/Comp Comp

That's all you need to do. WINDOWS and UNIX users will both see the projects the same way even though the data has been physically moved.

All the above can be scripted so that a single command will create a new project, all the physical directories and both sets of links to your default storage locations.  Also, you should customize your pipeline tools so that the link-based system is used and stop any tools looking at specific mounts and/or filers.