As an accountholder in the DMA labs you are entitled to space on our server for your own use. In addition, lab machines have a great deal of hard drive space themselves, and many are equppied with CD/DVD writers to make backing up larger files easier. In order to help you make intelligent file management decisions, here are some facts:

• Lab machines generally have a 30-80 GB of "temporary" space, whereas your account has a limit (usually 2GB).

• Accessing your server space means making a connection from your local computer over the network to the server. Therefore your local computer, the network, and the server all have to be behaving well in order for you to access your files. Access to local drives depends only on the local machines.

• You can access your server space from anywhere on the internet, and you can publish documents in your server area to the web. You can only access lab machine hard drives from within the labs.

• Scratch areas on lab computers can be deleted at any time and by anyone using the machine. Your account area is only accessible and deletable by you and the network administrator.

• Optical media (such as CDs and DVDs) have a limited lifespan. Writable CDs can be damaged by exposure to light or by cracks even in the non-data side of the media.

Knowing is half the battle. The other half is making smart decisions. Here are some suggestions we've found helpful:

• Do not work on data "live" from the server. You should use your server space as a storage area. Download/copy files to the local machine (pick your platform from our sections to learn how to retrieve files from the server), work on those copies, and then replace the originals on the server. This will always mean you have two copies of your documents while you are working on them. If a network connection is broken or your computer crashes, you'll be less likely to lose your work.

• Don't store things to 'temp" areas and expect them to remain there. I see people carving out their own space in temp areas. While this may be helpful to separate your documents while you are working on them, leaving files on a computer while you are not there and expecting them to be there the next day is dangerous. Not only can other students delete your work, but if our staff finds that the temp drive is getting full or the machine needs to be imaged or something, all files will be summarily deleted.

• Don't store things on your "desktop" and don't count on your settings always being the same on the same machine. Desktops and settings should be seen only as conveniences. Storing things on your desktop places those files in "system" areas and may actually slow down the performance of your machine. Not only that, but user profiles are the second place we look when we want to make space on a machine, and we sometimes have to destroy them as part of regular maintenance.

• Do take frequent backups of your data! We can't stress this enough. Keep a copy on your local computer, a copy on the server, and store work overnight in zips or cds. All of the PCs that have CD writers will have the "Roxio" application installed, which will allow you to make your own data CDs easily. All of the macs come with Superdrives and you should be able to copy data directly to blanks. If you have accounts elsewhere (say, on BOL's server) and you have some really critical work, you should go ahead and make copies of your work to remote folders.

• Do not over-write your backups. We've had instances of people making backups only to then directly "save" their working versions on top of the originial. When the network connection broke, both versions were gone.

A word about the server "temp" space (on the "net" share): There is temp space available on the server. Since people sometimes want to transfer files larger than their account quotas from one place to another, the temp area is a good place to put those files so that you can then retrieve them from another computer or from home. Please try to delete your work in the temp area when you are done with it, and don't keep things there for more than a day. The more it is used up the more often we will be forced to clean it up ourselves, meaning your data is more likely to be uncerimouniously erased. Keep in mind that the server temp area is a temp space like any other, where files may be deleted at any time without warning. NEVER keep your only copy of a file on the server temp drive.

In order to maintain uniformity accross working environments in our labs, D|MA employs a unified authentication scheme based on LDAP. In the base tier we have an OpenLDAP-based server housing our directory of all users and groups. This directory uses a modified version of the smb-ldap schema in order to store standard unix account information as well as standard windows account information. The server runs on directory.design.ucla.edu on the standard LDAP ports with security provided by an iptables-based firewall. The base-dn for the LDAP tree is: dc=design,dc=ucla,dc=edu.

The second tier of the authentication system is the layer that provides an interface to the operating systems in our environment.

Linux:

On our linux-based systems this is provided through PAM via the pam_ldap module that it automatically configurable by authconfig.

Windows XP:

Windows authentication is provided through an emulated domain controller running the samba suite. We recompiled samba to include ldap support and set it up to act as a "Primary Domain Controller" for the DMA domain. User authentication requests are automatically passed from the samba server to the ldap server.

Mac OS X:

Mac systems can authenticate directly to an LDAP directory, but we chose to use an intermediary, our Xserve box, as a workgroup manager. The workgroup manager reads data directly from the LDAP server and then re-serves this data to the Mac OS/X clients. Since we do not employ the Apple schema in our LDAP tree we do not have advanced Mac workgroup functionality such as roaming profiles.

Because the same directory serves all users in all environments, UIDs, GIDs, and passwords are all consistent accross the environments. This also means that permissions and filesystems do not need to reflect individual one-off situations.

In addition to the LDAP system for conventional users, all back-end servers support an auxillary authentication means via the NIS/YP protocol. File.design.ucla.edu acts as the primary NIS server with safety.design.ucla.edu functioning as a redundant slave. Only administrators have NIS acocunts and it only affords them access to server machines (not front-end lab machines).

Tools exist today that make it easy enough for someone to create a web page without actually knowing very much of what is going on "under the hood". While this improves accessibility, it often creates issues unforseable to the author. Here then are some common issues and some tips for avoiding pitfalls.

Know a little about how the web works. When you type an address into your web browser, a lot goes on behind the scenes. First, your computer sends a request to translate the named address you typed in (like www.yahoo.com) into a numerical address (like 66.218.71.80). Then your computer initiates a connection to the web port on that numerical address (typically port 80) and introduces itself to the "server" on the other end by saying what kind of computer and browser you are using, what version of page transfers it supports, as well as a few other things (what page referred it to that site, perhaps). It also makes a "request" for the page you are interested in. The server then responds by giving you all of the information on that page. There are pages on the web that let you see this entire process in "action". For starters you can find out more about how a URL is translated by your web browser. The W3C has a page that gives you detailed information on the scheme of a URL.

Know some HTML. You can start by looking at an online Reference tutorial on HTML usage. Then there are sites that offer some advanced HTML reference.
Once you've created your own pages, you can have your HTML code "validated" by the W3C's online HTML validator. Another useful tool is the Doctor HTML quality assessment for the web.

Above all, don't just let a program create the thing for you and ignore the underlying code. Web browsers only care about the underlying code, not how it looked on your computer when you designed it. If the code is bad, your site will reflect it. One good way to get good code is to ensure XHTML compatibility.

Think about your site as a whole. There are plenty of online guides to writting up a web page, but not quite so many that deal with how to treat your site as one entity. Yale has long published their Guide to organizing your website as a way to avoid some common mistakes in making things inaccessible or otherwise cumbersome. Remmember that just because you might think something looks better one way doesn't mean people won't develop ways to go around what you've done or just leave your web page if they can't find what they want.

Keep in mind that your site might not always exist in the same place. To that end, use RELATIVE as opposed to ABSOLUTE links (../foo/index.html as opposed to http://users.design.ucla.edu/~me/foo/index.html). Store anything fairly changeable in seperate files that you include in your other pages.

Learn about the technology. There are lots of other technologies besides HTML involved in setting up a web page these days. For large sites, you can look at this guide to Cascading Style Sheets (CSS). For help in creating dynamic pages, you can lok at web languages such as Java or PHP or generic information about the Common Gateway Interface (CGI)


There are even sites designed to improve your presentation, like this site explaining how best to use Adobe's Flash software.

Be aware of different technologies out there Fundementaly, the web was not designed for page layout. The web was designed so that you could mark up information with contextual descriptors and anchors, and navigate from one place to another. Only recently have people try to put consistent layouts and presentation on top of the web architecture. Unfortunately it doesn't always work so well.

Different browsers, for instance, don't always interpret pages the same way. The most popular browsers out there are Microsot's Internet Explorer, Netscape's Navigator, Mozilla Firefox, and Opera. But there are also web browsers that are entirely text based, such as lynx. Disabled people, people on mobile phones, people using old versions of AOL and many others use entirely uncommon browsers that still comply to web standards.

Also keep in mind that different technologies don't always speak clearly to each other. That can even be a problem with different versions of the same language. Java 1.0 and Java 1.3 are probably going to have trouble interoprating. If you build your site using ASP, chances are it will only work particularly well for someone browsing from a Windows-based machine.

Make your site works with your server. Apache is the most commonly used web server on the internet. It lets you do a great deal more than just regular HTML. Take a look at this guide to apache modules which will let you know what is happening on the server as opposed to on your page.

Be in compliance with the law and UCLA rules. Check with the Library of Congress using their Copyright Search tool to verify other copyrights. Plenty of sites on the internet will help you understand copyrights, such as this 10 Big myths about copyrights site.

UCLA also has its own policy on electronic communications.

One of the most frustrating things to deal with as a systems administrators is users who need help but do not give us enough information to understand a problem. Here are some general guidelines:

1. Read the the FAQs first. If you come to us with a question that we have already answered plainly and directly online we make make a face at you and then help you anyway. We really do try to keep our support site up to date and correct. If you find something wrong or unclear with the information on the site, we would love to hear about it so that we can make it better. It makes more sense for you and for us to go through the site. It lets you get answers to questions from anywhere and from a reliable, checked source that isn't busy doing something
   else. And it allows us to not have to answer the same questions over and over again.
   
2. Be specific! We would prefer to read a short novel than a one-liner. "My Machine isn't working" is as useful to us as you telling someone that you like
   the book you're reading when they don't know who you are or what book you are reading...
   
3. Include lots of details. Are you working on a Mac or a PC? What software are you running. What exactly did your error messages say?
   
4. Try some basic troubleshooting yourself. About half of the times we go to "fix" a machine where someone can't log in, it is because the network cable was unplugged from the back or because the user wasn't reading the instructions plainly
   in front of them. You can learn even learn something by trying to figure out what is wrong.
   
5. Try replicating the problem . Assuming your problem isn't one that caused you to lose all of your files or something, making sure that it always
   happens the same way, regardless of what machine you are on or what else you are doing at the time is a good way to narrow down what the problem is.

Our lab environment attempts to be a heterogeneous mix of operating systems and hardware platforms. Because technology changes quickly there is never one and only one method of accomplishing tasks. Unfortunately, moving from platform to platform is not yet a simple case of just relocating your chair and expecting everything to work. Here are some of the main differences in how systems deal with files from a user perspective:

Macs (even with OS/X) use "resource forks" and "data forks" for storing file information.

This means that when you save a file on a Macinstosh, you are actually saving two seperate branches. One contains the "data" section, the other contains information like the icon, associated program (what you use to open that file), creator, and other such information. Unfortunately, the break isn't even that clean cut, as some applications, notably Director, will actually store important information in the resource forks of its "documents". And whereas many documents are still useful with just their data forks, Mac applkications require both forks in order to run.

How do you deal with resource forks? The easiest way is to keep Mac files on Macs. Transfering them to servers or to PCs causes some program along the line to "split" the file into its two seperate forks. If you must transfer files to a server, using Stuffit or BinHex to "archive" the file first makes it so that the two seperate forks get combined into one file for uploading and no data is lost (but you do have to archive/unarchive at each end).


If you are simply dealing with docuements, making sure you use extensions is a good idea (name your JPEGs with a.jpg and your text files with a .txt extension, for instance). Programs like Fetch automatically translate extensions into resource forks when they are dealing with "common" types of documents.

The other thing to be careful of is using various different systems to transfer the files. In the DMA alone we have used Novell, Dave, Netatalk and Windows as means of "splitting" files. If you split a file one way you can only re-combine it that same way.

Windows uses filename "extensions" in order to determine what program to open a document with

Those pesky 3-character endings (like .txt and .doc) actually tell the operating system something about the documents its looking at. If you leave them out or change them, Windows will likely misbehave when trying to open the file. What's worse, Windows by default will "hide" the extensions of files of "known types", meaning you only see what program is associated with the file, not why that association took place.


Things get even more complicated when different programs "compete" to have file types "associated" with them. For instance, many programs can open up a JPEG image (.jpg). By default Windows associates anything with a .jpg extension to Microsoft Internet Explorer. Another program, like Photoshop, might then be installed and claim that it should handle .jpg files. Some programs go so far as to try to re-claim all file types it can handle whenever that program starts up. Some even do so without asking or telling you.

How do I know what extension is associated with what program? Go to My Computer, select the menu item Tools -> Folder Options. Click on the "File Types" tab. All of your associations are stored there.


How do I view extensions on my files? For one file you can just right-click and select "properties". To re-enable file extension viewing system-wide go to My COmputer and select the menu item Tools -> Folder Options. Click on the "View" tab and uncheck the box that says "hide extensions of know file types".

Windows and Macs don't differentiate between uppper and lower case. Unix systems (and most web browsers) do.

This means that you might not even know if a file has its first letter capitalized or the entire name capitalized. When transfering files to a web server, it is critical that your HTML and your filenames agree on what case your files are. The easiest way to deal with this is to make sure all of your files are named using only lower case.


How do I know what case my files actually are? This is a good question without a simple answer since Macs and PCs actually make it difficult to discover this. The best way to get at the information is to use the command line (terminal in OS/X) to list files. Since this is complex, an easier though more cumbersome method of discovering is to use the SFTP program to transfer the files to the server. The SFTP program will then show the actual casing of the file as it resides on the server.

Not all characters are created equally when it comes to file names

Macs have always allowed spaces in their filenames, but Windows95 was the first OS to introduce that on the PC side. Other characters, like ; * % $ @ ! " ' ~ and ~` have special meanings in different operating systems. The best way to avoid file naming issues is to not using anything but letters, numbers, dashes (-) and underscores (_) in file names. Anything else and you are asking for trouble.

Windows uses backslashes (\) whereas unix/macOSX uses forward slashes (/) when seperating directory paths.

This means that full directory names do not translate well between the two systems. Some programs (like ZIP) will try to do their best to convert between the two systems. Others will simply look at the wrong-way slash and fail. In short, don't count on directory paths to be a solid way of describing a file's location

Text files are different in Dos systems (Windows) and Unix systems.

Text files in DOS end with two hidden characters -- a line feed and a carriage return. Text files in Unix end with just one. Therefore, when transfering a text file from one to the other you can expect unexpected results (like garbled lines or funny looking black hash marks) if you fail to run a conversion program. Unix boxes generally come with a "unix2dos" and a "dos2unix" utility which you can use to change the files.