H. MISC.
H.1 Booting a server without running STARTUP.NCF/AUTOEXEC.NCF
There may be times when you want to boot a file server without running the startup scripts C:\STARTUP.NCF and SYS:SYSTEM/AUTOEXEC.NCF. With NetWare 3.x, when you issue the SERVER command, include the parameter
-ns To not execute the STARTUP.NCF -na To not execute the AUTOEXEC.NCF
Note1: These parameters are case sensitive and MUST BE lowercase.
Note2: NEVER load memory management software before running SERVER.EXE!
Under NetWare 2.x all of the configuration information is incorporated into the NET$OS.EXE file so the question doesn't really apply; you would have to regenerate the operating system with NETGEN to change it.
[Thanks to Jay Sissom for clarifying the 2.x issues]
To start server with another STARTUP.NCF type:
SERVER -S START2.NCF
To start server with another AUTOEXEC.NCF type:
SERVER -A AUTO2.NCF
To start server without Directory Services open use -NDB and to start server in internal debugger use SERVER -D (this is the only documented option: type HELP RESTART SERVER on System Console). Options seems to work with RESTART SERVER command.
[Thanks to Petr Jaklin for this info]
H.2 How to login without running the system/user login script
The DEFAULT login script built into LOGIN.EXE executes after the SYSTEM login script (NET$LOG.DAT) when there are no USER login scripts. The solution is to either use an EXIT command at the end of the SYSTEM login script or create individual USER login scripts. The latter approach is more work but there is security benefit to creating USER login scripts.
Among other things the DEFAULT login script maps S1 and S2 search drives to SYS:PUBLIC and to the DOS subdirectories under PUBLIC. It also attempts to map a user home directory immediately under SYS: For more information see the Installaton and Upgrade red book. By the way you cannot modify the DEFAULT login script because it is built into LOGIN.EXE so the best you can do is prevent it from executing.
[Thanks to Andrew Lampert for this info]
In NetWare 3.12 and above, or earlier versions upgraded to the latest LOGIN.EXE, you can use the NO_DEFAULT login script command to prevent the execution of the default user login script for users who have no personal login script.
[Thx S.M.D.]
Alternatively, you could ensure that every user has a NetWare login script, however small, and that there is a system level NetWare login script as well. By the way, use "PATH string" as opposed to "SET PATH=string". The former goes through command.com for regularization, the latter is taken verbatim.
[Thx Joe D.]
This last point is a good idea from a security standpoint, too. Basically, on a server where users are allowed to have their own personal login scripts, an account without one may be a security hole. For the details, see the Hacking NetWare FAQ at:
http://www.nmrc.org/faqs/netware/index.html
A number of Netware hacking files and additional info are at:
and
[Thx S.M.D., Gabor Borsodi and Simple Nomad]
Or, you could ATTACH instead of LOGIN to the NetWare file server(s). You will either need to first login to another file server which has the ATTACH command available or copy ATTACH.EXE to the workstation's disk. Then enter the login command as "LOGIN /S nul *username*" which will attempt to read the script from the DOS nul device, which always returns end of file, effectively avoiding reading a login script.
If you are running NetWare 4.x you can LOGIN /NS (/NS meaning No Script). In a 3.x environment use LOGIN /S... Use /S to point to a text file on a local drive containing login script statements (A simple WRITE "It worked" should do) The easiest way of all is to LOGIN to another server and ATTACH to the problem server. If security is not an issue, copy ATTACH.EXE to your sys:login directory to avoid future problems.
[Thanks to A. Murray for this info]
At least in 3.1x, the Login scripts are in the mail directory. So the supervisor Login script is at sys:mail\1\login. If all login scripts are going to be the same, set the system Login scripts to what you like it to be and have only exit in the user login script. You don't want to leave no login because people have write access to the mail directory and can store a login script that causes problems. If there is something there, they can't change it.
[Thanks to Tom Tuckerman for this info]
H.3 Remotely controlling a PC with a telnet compatible program
To use Telnet to remotely control a PC, get telnetd.zip at:
http://www.futureone.com/~opeth/internetwork.html
[Thx S.R.#2]
It works really well with CUTCP TELNET, and also works fine with MacTCP TELNET and most other TELNETs as well.
H.4 Getting userIDs and other information into programs
There are essentially four ways to import Novell information into programs you have written, each of which is appropriate for some solutions:
Use the login script command:
dos set VARIABLE="Value"
to put the user-id (%LOGIN_NAME), station number, etc. (consult the Novell documentation for the list of available values), into an environment variable. Now you will be able to retrieve the environment variable in both batch files and programs. In Turbo Pascal as well as most varieties of C and C++ use the expression GetEnv("VARIABLE") to retrieve an environment variable.
This technique is good for simple programs which only need a few Novell values, and for batch files.
H.4.2 Piping in information from WHOAMI
Write your program to read its input in the form that WHOAMI types, and then pipe in the output from WHOAMI:
WHOAMI [/a] | YOURPROGRAM
You will have to program to ignore lines that contain only / - \ because these still appear at the head of the file while the program is scanning the bindery information.
This is inefficient, but it is the only way to get arbitrary group memberships if you cannot use the H.4.3 or H.4.4 below.
Purchase the Novell APIs, available in both C (which work with several versions of C and C++, including all Borland products) and assembly language (which you could also use in any high level language with an interrupt command). With these you can retrieve directly almost any information that the account running the program has access to. The APIs provide not only basic services like user-names and connection number, but advanced ones like print queues and IPX/SPX communications, among others.
This is the best and most efficient solution, but requires investment in the APIs as well as programming knowledge.
You can order the Novell SDK by calling 800-RED-WORD or 801-429-5281. The Novell SDK is made available by subscription. The base price is $345 per year. This includes four releases of the SDK CD, a choice of a Novell product for your development/test environment, and a support incident. For further details please see http://developer.novell.com
Documentation may be viewed at http://doc1.provo.novell.com/
[Thx J.P.]
An alternative to the SDKs is "Programmer's Guide to Netware" by Charles Rose. This book has extensive details on Netware v2.x system calls and covers many Netware v3.x calls.
There is also a shareware API library available via anonymous FTP at:
ftp://ftp.coast.net/SimTel/msdos/c/netclb35.zip
or any SimTel mirror site.
[Thx A.C.]
A Pascal NetWare API supporting programming language is NWTP06. It stands out because it is very complete (it does not however support Netware 4 as yet) and is available at:
ftp://novftp.rc.rug.nl:/proglibs/nwtp06.zip
It contains over 400KB of sources in more than 250 interface functions, over 500KB documentation and more than 200KB samples. The author is Rene Spronk.
[Thanks to Olger Diekstra for this info]
UPDATE.EXE is by Robert Evans <bob@purdue.edu> is a freeware utility that allows you to detect the existence of specific sub-strings in text files, add, replace, delete specific lines, files, directories etc.
ftp://ftp.soe.purdue.edu/pub/update/
[Thx D.L.]
USERDUMP by Roy Coates will tap the bindery and list user info such as mail address, user id, etc. and is available at:
ftp://ftp.mechnet.liv.ac.uk/novell/freeware/userdump.zip
or
http://www.mechnet.liv.ac.uk/~roy/freeware.html
[Thx R.C.]
DISKHOG by Roy Coates will list the disk space used by user, including subdirectories and is available at:
ftp://ftp.mechnet.liv.ac.uk/novell/freeware/diskhog.zip
or
http://www.mechnet.liv.ac.uk/~roy/freeware.html
[Thx R.C.]
H.5 What do all those columns in STAT.NLM v2.0 mean?
STAT.NLM is a process which records performance information for a Netware v3.11 file server. STAT records a data point once per second and writes to the disk once per minute to minimize the effect on the server.
Use DUMPSTAT to output the STAT data in a readable format. This is a DOS command and its syntax is:
DUMPSTAT inputpath [outputpath] [-L | -X | -S | -Nnum | -Mnum]
where -L Lotus format (comma delimited) -X Excel format (tab delimited) -S Screen format (column justified) -N Output file size (default is 7200 points or 2 hours). You can increase this if you want to put a day's worth in one file, etc. A file with 8 hours of data would therefore have -N28800. -M Data reduction factor ... or do you really not want that much data. This is the number of records that will be averaged and output to a single record. So putting 60 in here would give you a point per minute instead of a point per second. 300 would give you a point per 5 minutes.
Here is the official word from Novell on what the columns of output mean:
1. CPU utilization 2. Bytes received (bytes read from LAN comm channel) 3. Bytes transmitted (bytes written to the LAN comm channel) 4. Bytes read (bytes read from the disk) 5. Bytes written (bytes written through cache to the disk channel) 6. Packets routed (# packets using the router services of the server) 7. Number of connections
An important warning for anyone using STAT.NLM: the next filename to be used by STAT.NLM is stored in a file called STAT.CFG. You must use the STAT configuration utility to change this -- using a text editor will most likely crash your file server.
[Thx G.F.]
H.6 Changing the number of licenced users on a Netware server
This answer refers to Netware v3.1x only. The serial number and maximum connection count are both found in SERVER.EXE. When you get your upgrade package from Novell, copy this file from the SYSTEM-1 diskette over your old SERVER.EXE on your server's boot diskette or boot partition and your server is upgraded. Note that it might be wise to keep the old SERVER.EXE around in case you later discover that the new SYSTEM-1 diskette has a media error or something. Also, if you have applied any static patches to your old SERVER.EXE, they will have to be re-applied to the new one (semi-static and dynamic patches, loaded in your AUTOEXEC.NCF, do not modify SERVER.EXE and will continue to work as usual).
[Thx S.M.D.]
H.7 Register memory ("Cache memory alloc. out of avail. memory" msg)
This section is based on NOVELL FYI 1.1.39, extended to include information provided by George Whitehead, R.J.L., Joe D. and S.M.D.
ISSUE/PROBLEM
Server error message: Cache memory allocator out of available memory.
This can occur when mounting disk volumes even when there are plenty of cache buffers available in machines with more than 16M of memory. It can also occur I guess when you have run out of memory completely but the solution in this case is obvious.
SOLUTION
EISA machines should be configured to use AUTO REGISTER MEMORY, but in the case of ISA machines or EISA machines that are not configured correctly, the following kludge will solve the problem. Every machine that requires the REGISTER MEMORY command, uses more than 16MB of RAM, and has large disk storage, will exhibit problems such as this. This is not an issue in machines that do not require the REGISTER MEMORY command (such as the COMPAQ SystemPro, PS/2 MODELs 90, 95, HP Vectra etc.) because at boot up you see all of the RAM.
By the time you register memory in the AUTOEXEC.NCF, volume SYS: has already been mounted. At the time the first volume is mounted, NetWare draws a line in the sand, and only memory which it had available at that time can be used for FAT caching for all subsequent volumes, regardless of how much physical memory is available at that time. Therefore, subsequent volumes will be mounted downward in memory until you eventually run out of memory below 16 meg (see figure 1 below).
Figure 1:
|======{==}={==}={==}| ==========================|
{== VL2 VL1 SYS 16 64
MEG of MEMORY MEG
The key is to REGISTER MEMORY before loading the disk drivers or mounting volume SYS:, as illustrated in figure 2 below.
Figure 2:
|===============|=================={==}{==}{==}|
16 { = VL2 VL1 SYS 64
MEG of MEMORY MEG
Here is the procedure:
Step 1. Remove ALL DISK DRIVERS out of the startup.ncf file. If this is all that startup.ncf has then delete it.
For example my startup.ncf is: set minimum packet receive buffers = 200
Step 2. Create an Autoexec.ncf file in the same DOS directory as SERVER.EXE, making sure that the register memory command is executed before volume SYS is mounted. Use the format listed below.
file server name HOPE ipx internal net 9088 register memory 1000000 1000000 load isadisk port=1F0 int=E mount SYS autoboot
Step 3. Create an Autoboot.ncf file in the SYSTEM directory. Put into it all other Autoexec.ncf commands.
load NE2000 port=300 int=3 frame=ETHERNET_802.3 bind IPX to NE2000 net=01abfeed etc.
The decision to use the name autoboot is purely personal. The mechanism will work with a single Autoexec.ncf on the DOS drive containing all of the autoexec.ncf commands. The advantage of the 2 file method is that the complex part of the autoexec.ncf file is on the Netware partition and can be edited from a workstation using your favourite editor while the server is up. Others may find it preferable to have a single autoexec.ncf on the DOS partition of the server as this allows access to it when the server is down.
[Thanks to George Whitehead, R.J.L., Joe D. & S.M.D.]
Related bits and pieces.
Joe D. posted a message to the NOVELL LISTSERVER at the start of July (1994 Joe?) which described how to configure EISA memory cards.
Earlier versions of the driver for the ISA/MCA Adaptec host adapters (154x and 164x series) had a command-line parameter which informed them that they were operating in a machine with more than 16 MB of memory. Current versions of the drivers for these cards do not require this parameter and the EISA cards have never required this parameter.
Some drivers may require:
set reserved buffers below 16 MB = 64
[See H.16 for more info on Adaptec]
It is possible to 'RUN' a sequence of netware console commands from a batch file by typing the name of the file from the console. Put the commands in a file in the SYSTEM directory and give it an NCF extension. For example if the file was called TEST.NCF it could be run by typing TEST, then pressing ENTER, at the console prompt.
[Thanks to Douglas Scott and S.M.D. for the info]
Some EISA don't register memory above 16MB. If this is the case, the NSEPRO describes the solution for servers running NW4 is to put the following lines in STARTUP.NCF:
SET AUTO REGISTER ABOVE 16 MEGABYTES = OFF SET RESERVED BUFFERS BELOW 16 MEG = 200 ...load the disk drivers LOAD MEMFRGFX
[Thanks to ksommers for the info]
Also, make sure there is no interrupt conflict. Drew Morris reported problems when a PCI SCSI card was set to Interrupt 15 and another problem when a PCI adapter was on Interrupt 9.
[Thanks to Drew Phillips for the info]
Additional note: Netware 4.x auto-registers memory in a PCI-bus server but Netware 3.x doesn't...unless you have more than 64 MB of RAM. Above 64 MB you will have to register manually, which can be done in the NetWare 4.x STARTUP.NCF file.
[Thx A.S.]
TID500055 Mounting Volumes and Memory Allocation
Some Early Information About Mounting Volumes May Be Misleading
Documented issues about registering memory on ISA and some EISA machines have been interpreted to say that NetWare mounts volumes from the top of the memory block down. That model seemed to explain the memory limits for mounting volumes and the necessity to avoid mounting the SYS volume before registering all memory. While it is true that all memory should be registered with NetWare before any volumes mount, it is not true that volumes mount from the top of the block down.
How NetWare Uses Memory to Mount Volumes and Grow the Directory Hash Table
Mounting a volume consists largely of reading the FAT from disk into server memory. After the FAT is loaded then the DET, directory entry table, is scanned and a hash table is built in server memory. Two simple rules govern the allocation of memory for mounting volumes. The first rule: when the first volume mounts, NetWare defines a block and all subsequent volumes will mount in that block. The second rule: the memory allocated for the volumes grows from the bottom of the block upward. The DHT, directory hash table, will be in the same block and, like volumes, will grow from low to high. Assuming the block in question to be the only block then any NLMs loaded or other cache buffers required will be allocated from the top of the block down. In summary, volumes and DHTs grow from the bottom of the block up and NLMs and other cache buffer requests use memory from the top down.
[Thanks to Mark Cramer for this info]
H.8 Where to get the Windows NT requester
A new version of the Windows NT client requester is now available at:
ftp://netlab2.usu.edu/updates/nwos/ntclnt For Netscapers: ftp://netlab2.usu.edu/sys/anonftp/updates/nwos/ntclnt
[Thx H.K.]
H.9 Why can't I format a floppy under Windows when using boot ROM?
When remote booting, the NIC takes the place of the machine's A drive as the startup device (Note: the boot image is nothing more than an image of a bootable floppy disk). DOS notes this by marking drive A as the startup device. To avoid wiping out your DOS and Windows system, Windows won't let you format your boot disk/system disk. Jeff Macdonald has created a shareware program for use with Windows that "fools" Windows into thinking that the C drive is the startup drive, thus allowing Windows to format the A: drive. The file is called FAKESTUP.COM and can be found at many of the Novell sites including Joe D's site:
ftp://netlab2.usu.edu/apps/fakestup.zip For Netscapers: ftp://netlab2.usu.edu/sys/anonftp/apps/fakestup.zip
[Thanks to Doug Williams for this info]
H.10 Getting a list of usernames on a server to an ASCII file
John Baird of New Zealand has developed a range of tools for Netware which are widely regarded as essential for supervisors. One of these is GRPLIST, which will list all users in a group. To get all usernames into an ASCII file, issue the following command:
GRPLIST * /f
which will create a file called USERS.LIS containing all user names on the server. John's utilities are available from most of the ftp servers listed in the FAQ (section C.2), as well as at:
ftp://netlab2.usu.edu/apps/jrb400a.zip For Netscapers: ftp://netlab2.usu.edu/sys/anonftp/apps/jrb400a.zip
H.10.1 Creating users from an ASCII file
There are at least two programs that will create users based on input from an ASCII file.
Mass User Management reads in a tab, comma or space delimited file and creates the users. It uses templates to match different user account restrictions to different users in the ASCII file. A demo is available at:
ftp://ftp.coast.net/SimTel/msdos/novell/MUM13B.ZIP
This version of Mass User only works in bindery emulation on NetWare 4.1 servers so all users must be in the same context. An NDS version is in the works, though. Co-authored by Shawn_Holmstead@novell.com and others. Now works with VLMs.
H.10.1.2 UIMPORT -- reads an ASCII text file and adds users
UImport reads an ASCII text file and adds users. I know nothing further.
H.10.1.3 ScanUser -- scans/creates unknown/missing Mail directories
ScanUser is a small utility that scans for unknown or missing Mail directories, with the option to create missing ones. It is for sites with many users, and avoid the bother of logging in each user with /b to create the Mail directories. It also searches for Unknown Mail and Home Directories. ScanUser is free but you are asked to register if you are using it at: http://www.petena.se/support/register.htm You can get ScanUser at:
http://www.petena.se/software/
[Thanks to Peter Stromblad and Johan Wahlen for this info]
There are a variety of ways to get access to your network remotely. These include running a telnet server (e.g. telnetd described elsewhere) on a workstation and accessing it via tcp/ip, running remote control clients and accessing them via modem, running remote network node clients and accessing them via modem and of course iptunneling across a tcpip network.
Conceptually and practically, the simplest solution for many people is to run a remote control client on their own workstation which they dial into and control from remote sites. This requires 2 modems (preferably fast ones using V.34, or V.32bis in a pinch) and also requires that you leave your workstation permanently turned on - in itself arguably a Good Thing provided that the monitor is off. It also requires some software and there are a large number of choices.
Commercial packages include PC-Anywhere, CloseUp, Blast, Carbon Copy and Reachout (Stac Electronics, 1201 19th Place, Vero Beach, Fla 32960 (407)770-4777, FAX: (407)770-4779, TECH: (407)563-2255, www.stac.com). These cost around $100 to $200 per node and often work quite reasonably.
Shareware packages such as Telereplica (check your SimTel mirror)
ftp://ftp.radio-msu.net/.1/.m/Coast/msdos/modem/tr4-26.zip
offer a very cost effective solution. Telereplica has long passwords which are very hard to crack and can even do dialback for added security. The only drawback is that it does not do graphics but at 9600 baud, life's too short anyway! If you really need to run a graphics package (e.g. Harvard Graphics or whatever), do it at home and upload the results to your workstation. It's much faster that way !
There's also PCRemote from PC Magazine.
ftp://ftp.cdrom.com/.5/asme/COMM/PCREMOTE.ZIP
PCRemote has assembler source for a simple remote control package via modem which could be the basis for a more sophisticated effort.
[Thanks to Dr Ross Lazarus & S.R.#2 for this info]
One of the Very Frequent Questions on this list is how can folks dial into their NetWare file server.
At present, they can't, at least not like they think they might. Some device has to act as a client node on the network and then put things into a form suitable for async transmission. Whether SLIP or PPP or another framing method is used normally is a small part of the picture. In any case, the server is not an interactive login machine such as a Unix box and DOS does not work to a classical terminal interface.
This means the node on the net can execute the DOS programs and relay screen and keyboard updates across the phone lines (Carbon Copy, PC Anywhere, et al), or it can try to wrap IPX packets into async frames and unpack them on the other end. Things such as Netblazer/Worldblazer modems (though by now "modem" is the small part) act as such relay nodes. Novell's Access Server, and similar boxes, run a bunch of DOS machines having keyboard/screen relayed across the net. NAS simulates many machines on one via a special version of DESQview.
Since you have LWP/DOS 4.1, have a look at the XPC part of things. The idea is to relay the keyboard/screen of a DOS machine executing the program of choice across a wire using IP packets and the X window system protocol on top. Thus you could execute WordPerfect/DOS sessions from your Sun workstation, with your DOS PC doing the real work. Taking one more step, put a modem on your office DOS PC, run XPC there, and at home fire up a PC running X to a matching modem.
You might want to look at:
ftp://netlab2.usu.edu/..???../brainshr.zip
which is basically the floppy disk passed out at Brainshare/SLC (aka Novell Developer's Conference) this spring by Brian Meek addressing LWP/DOS, dialing, SLIP_PPP, and even Kermit's role in this. The development Kermit was just for developers, is out of date and should not be redistributed.
[Thx Joe D.]
H.12 Short Term Memory -- how much does your server need?
The default Short Term Memory allocation will ALWAYS crash your server if any type of load is put on it. I would suggest that you immediately set this value up to 5000000. We happen to run our servers at 8000000.
The exact syntax, which can be placed in your AUTOEXEC.NCF would be,
SET MAXIMUM ALLOC SHORT TERM MEMORY=8000000
[Thx G.F.]
Long term readers will recall my personal recommendation is to use the maximum amount of memory in the machine, or NW's limits, whichever is smallest, in this line. I don't have much factual information to go on, but my crystal ball says it makes a pool available contiguously and helps NLMs when their memory needs arise. It does not hinder other memory allocations nor consume cache buffers etc.
[Thx Joe D.]
H.13 BTRIEVE -- what do I need?
Btrieve is a record manager running as an NLM on a Novell server. Certain applications can use a Btrieve client to make requests to the engine on the server. BTRIEVE.NLM is the server component, while BREQUEST.EXE is the DOS client. More complete documentation is included with the Novell manual set.
When performing installs of some programs, make sure the btrieve related programs in sys:system are NOT flagged as read-only.
Btrieve is no longer part of Novell. Btrieve Technologies can be reached at: #300 - 8834 N Capital of Texas Hwy, Austin, TX 78759-9774, Tel: 800-BTRIEVE (US & Can), 512-794-1719, eMail: Info@BtrvTech.COM, http://www.btrieve.com
[Thanks to Mark Fogel, H.K. & R.J.L. for this info]
H.14 What to do if you've lost your SUPERVISOR password.
Panic. :-) In fact there are several options you can try.
SETSPASS.NLM, available via anonymous ftp from netlab2.usu.edu in misc or:
ftp://ftp.zennet.com/pub/netware/
[Thx S.R.#2]
allows you to change the SUPERVISOR password from the server console, as long as you know the serial number of your copy of Netware.
SETPWD.NLM, that doesn't require that you have the serial number, is located in the same directory.
LASTHOPE.NLM will "zap a corrupt bindery" but seems to suffer from poor (i.e. missing) docs.
ftp://netlab2.usu.edu/sys/anonftp/apps/lasthope.zip
If you have some unallocated disk space on the server you could create a new SYS: volume on that. This will create a new bindery as well as LOGIN, SYSTEM, PUBLIC and MAIL directories. However it is a bit drastic.
Alternatively, *FOR NETWARE 2.X SERVERS ONLY*, you can try the following:
1. Bring the server down.
2. With some disk sector editing software (Norton Disk Edit for
example) find the directory tables.
3. Change the name of files NET$VAL.SYS, NET$PROP.SYS, NET$OBJ.SYS
to something else (preferably NET$VAL.OLD etc.)
After that all user definitions will be deleted.
4. Bring the file server back up.
5. Login as supervisor (at that time you will need no password)
6. Find changed files in SYSTEM directory (they have attributes
hidden, system), change their attributes to normal and
be sure that they have extension ".OLD"
7. Run BINDREST program to get your original user definitions back.
Now, you will have all your users including supervisor with
their old definitions and passwords, but you are already in as
supervisor and so you can change your password to anything you like.
Note: It appears that in NetWare 2.x there are only two bindery files. For more information on this see the Hacking Netware FAQ at:
http://www.nmrc.org/faqs/netware/index.html
A number of Netware hacking files and additional info are at:
and
[Thx S.M.D. and Simple Nomad]
You can also try to use your sector editor to edit the names used for the bindery files in SERVER.EXE. Unlike the previous NETWARE 2.X ONLY method, this has the advantage of not damaging the directory tables if things go wrong. Try the following steps:
1. Bring the server down.
2. Make a backup copy of SERVER.EXE.
3. With some disk sector editing software (Norton Disk Edit for
example) change the name of files NET$VAL.SYS, NET$PROP.SYS,
NET$OBJ.SYS where they occur in SERVER.EXE to something else
(preferably TMP$VAL.SYS etc.)
4. Bring the file server back up.
5. Login as supervisor (at that time you will need no password)
6. Find changed files in SYSTEM directory (they have attributes
hidden, system), change their attributes to normal and
be sure that they have extension ".OLD"
7. Bring the server down again.
8. Restore your backed-up SERVER.EXE and reboot.
9. Run BINDREST program to get your original user definitions back.
Now, you will have all your users including supervisor with
their old definitions and passwords, but you are already in as
supervisor and so you can change your password to anything you like.
There is a program called BURGLAR that is designed to break passwords at:
ftp://ftp.rhij.nl/cyco/burglar.nlm
Note: BURGLAR creates a tempory user that is incomplete. Log in under this users name (and remove the account after use). BURGLAR was written by Bart Mellink from Cyco.
There is additional information in the Hacking Netware FAQ at:
http://www.nmrc.org/faqs/netware/index.html
A number of Netware hacking files and additional info are at:
and
[Thx S.M.D. and Simple Nomad]
H.15 Synchronising workstation time with server time
Time synchronization occurs at two times. The first is at the time when the shell or redirector makes a connection to a server (the NOT-LOGGED-IN connection which gives you access to SYS:LOGIN). To disable this connection from setting your workstation's time, use SET STATION TIME = OFF in your NET.CFG.
The second time is during the login process. In the absence of a SET_TIME OFF command in any login script executed by the user, the workstation's time will be set to that of the fileserver. This command is supported in the LOGIN.EXE which ships with NetWare 3.12 and 4.x; it can be downloaded from the usual places for earlier versions.
[Thx S.M.D.]
The synchronization of workstation and server clock is explained in the Novell Application Note "Time in the NetWare Environment", Jan 94.
[Thx M.W.]
[ H(1) | H(2) | H(3) | H(4) | Novell FAQ Home Page ]