Step 1: Password Synchronization
The CCIS Systems group has arranged after much effort that you may
use the same password for UNIX login and Windows login. However,
this is not quite automatic.
The problem is that when a UNIX account is first requested, this
request must be validated by Systems and so no corresponding
Windows account is created. Hence, the Windows password cannot
be synchronized with the UNIX password at the time when the UNIX
account is first created.
The UNIX password and the Windows password will become synchronized
each time you change your UNIX password! To do this, login
to the UNIX systems and issue the passwd command.
So, if you have never changed your UNIX password, you must do it at
least once to achieve password synchronization. Many people change
their password twice, once to a temporary password and once to make
it the same as their original password.
One more issue. Windows requires that a password be at least
7 characters at that it include 3 of the following 4 groups:
- Upper case letters
- Lower case letters
- Digits
- Punctuation
At the same time, UNIX has a password limit of 8 characters. Hence,
password synchronization will fail unless the password is 7 or 8
characters and includes at least one character from 3 of the 4
groups listed.
Step 2: Creation of your Home Site on the Development Server
After password synchronization, you must go through a set of screens
that will create a “home site” for you on the ASP.NET
“Development Server”. To do this, follow the link:
ASP.NET Development Server Accounts
Be sure to record the SQL Server database password that you receive
since this password is different from your common UNIX/Windows
password.
Step 3: Creation of a Secure Shell Profile to your Home Site
To quickly login in the the “Development Server”, you
should create a “profile” in Secure Shell that maintains
the requisite information. Then, by selecting the profile, you start
the login in process.
Here is a screen snapshot that shows how I created my profile.
Notice that the host name is
development.ccs.neu.edu
that the login account name must be prefixed with
ccis-windows\
and that the port number is
22
The profile must be named and the name “development”
seems to be as informative as any.
Step 4: Login to your Home Site
Use the “development” profile to initiate a login to
your home site. You will be immediately prompted for a password
which is your common UNIX/Windows password. When that password
is entered correctly, you will see the screen:
You will notice the message:
Shell access has been disabled by the system administrator.
This means that you may not type anything into the shell window!
So what good is it? The answer is that you may now use secure shell
to open a file transfer window using the “Window”
menu. You will use this window to transfer files.
Step 5: File Transfer
When you open the file transfer window, you will see something like
the following only simpler.
Notice that, for my site, the home directory has 4 folders and no
files:
v2.0, www, rasalax, teachingfiles
Your directory will only have v2.0. My setup is a bit
more complex than yours for reasons I can explain in class.
You must place all files and folders to be served from your site
within the v2.0 directory.
Anything at top level will not
be served and anything in other folders created at top level will
not be served. The purpose of additional folders at top level is
to store information that your web application may access but that
cannot be directly accessed by a web user.
Below, you may see a screen snapshot that shows some of the content
from my v2.0 directory illustrating the fact that the
files and folders of a site should be in that directory.
You will do file transfer over and over throughout the semester
into the v2.0 directory as you build, modify, and
improve your site.
Final Advice. Although, in the CCIS labs, it is possible to
point Visual Studio to your directory on the Development Server
and then to edit your files, this is a terrible idea.
You must edit and test your site offline and you should
upload files to the Development Server only when you have a
reasonable probability that they will work correctly. Of course,
you may have bugs that need to be detected and fixed, but that is
what sometimes happens. However, to edit directly online is to
almost guarantee bugs and perhaps a broken site. This is simply
terrible software development practice.