8/4/2003
Eric Low

I started with a minimal RedHat 9 system (selecting "Minimum Installation" during setup), so the system was almost completely bare. I used the default partition sizes, meaning one small one for boot (hda1), one very large main area (hda2), and one medium area for swap (hda3). I also selected to assign the NIC an IP address via DHCP and use high security firewall rules.

First thing I needed to do after installation, of course, was to customize the kernel. I download the latest full kernel from kernel.org and extracted it. As soon as I ran make menuconfig, I got an error that said "Unable to find the Ncurses libraries. You must have Ncurses installed in order to run 'make menuconfig'" Yes, apparently this installation really was bare. So, off to Redhat to find the Ncurses RPM. I usually don't like RPM's, simply because I'd rather have the control that .tar.gz installations provide, but with this Mars-NWE installation I think I'd rather have the convenience and recordkeeping functions of RPM's. It turns out that Ncurses already was installed (although I did upgrade from version 5.3-4 to 5.3-5). So why the error? After a bit of searching, I found out that I needed the Ncurses-devel development package, since it contains header files that are needed by make menuconfig. I installed this (make sure the version matches the version of Ncurses you already have installed!), yet I still got the same error. I found a lot of places on the web that told me I needed libncurses-devel, but after looking around for quite a long time, I gave up. This is impossible to find for RedHat, so maybe it's not needed for anything after all.

Well, assuming it was part of the other error, I had completely ignored the "/bin/sh: line 1: gcc: command not found" error. So, I proceeded to download and install gcc and libgcc (3.3-14). This version of gcc also required me to upgrade glibc-devel, cpp, and binutils. glibc-devel also required me to upgrade glibc to the same version (duh), and install the kernel-headers, which I hadn't before. In addition, glibc required glibc-common of the same version. Finally, make menuconfig ran no problem.

Once all that was out of the way, I started on the actual Mars-NWE stuff. First thing I had to do was install ipxutils (2.2.1-1) (also known as the IPX Tools), which had an RPM and was fairly straightforward. This is a suite of the following four utilities: ipx_interface, ipx_configure, ipx_internal_net, and ipx_route. Next, I installed the actual Mars-NWE program, which I got directly from the RedHat site and therefore came neatly packaged in an RPM. Keep in mind that not much has been done with this project in a few years, so it is very difficult to find the newest version. RedHat had the newest I could find, which is 0.99pl20-12, although I know that a version 1.00pl exists which addresses some buffer overflow issues.

Mars-NWE has permanent settings compiled right in, which can be set before compiling by editing a file called config.h. Because Mars-NWE was installed with the RPM, editing config.h after running make is not necessary (if you like defaults). There is an example config.h in /usr/share/doc/mars-nwe-0.99pl20/examples/ that can be examined if you want to see what these default installation settings are. A file called nw.ini will be deposited in the same directory. If you were to compile manually, you could make changes to this file after running make twice and before running make install. However, all this would actually do is copy this file to /etc/nwserv.conf, which could be edited later anyhow.

If you need to recompile, you must download the Mars_NWE source RPM. This installed a bunch of files in /usr/src/redhat/SOURCES/, including a .tgz file called mars_nwe-0.99.pl19.tgz. I'm not sure what the deal is with the version number, but even my already installed version of nwserv claims it's version 0.99.pl19 even though it's actually 0.99pl20-12. Anyhow, I had to recompile, since there were a few default options I did not like. I extracted this .tgz file to a separate directory and ran make. This created two files, mk.li and config.h, the latter being the one I needed to modify to changed the compiled-in settings. Specifically, I changed the #define MAX_CONNECTIONS line from 50 to 200, and #define SHADOW_PWD from 0 to 1, since I use shadow passwords (as everyone should). I also did not want to use the default NETWORK_SERIAL_NMBR, and changed that as well.

As soon as I edited config.h and ran make again, I ran into compile errors. After some poking around, it turned out that a file called Makefile.o in the /obj directory was created wrong - there were many instances of spaces where tabs should have been. I manually replaced all of those spaces with tabs (the updated Makefile.o is in the download section at the bottom of this document - simply run make, then after you get the errors, overwrite the obj/Makefile.o with this version) and tried running make again. This time, I ran into a whole different set of errors about a missing ndbm.h file. As it turns out, this file is included in gdbm-devel. Once I installed that, Mars-NWE compiled just fine.

Now that I knew it would compile, I went back and edited nw.ini for our particular setup. Here are the changes that I made:

I also don't need to use the printing services from this server, so I completely commented out sections 21 and 22.

While I was editing the nw.ini file, I had to add two users - SUPERVISOR and ARCHIVER, mapped to the Linux accounts nwsupe and nwarchiver. To create these Linux accounts, I typed the following from the bash prompt:

Notice how I put nwsupe and nwarchiver in the same group - I had to do this because of the sucky way the Linux currently handles user rights (complete lack of ACL's (Access Control Lists)). I wanted to give nwsupe full control over each Netware volume, but give nwarchiver only partial rights. Therefore, I had to login as nwsupe and create the directories for those volumes, giving that account full rights (as the owner), and partial rights to the group that it belongs to (which nwarchiver is in).

I also made sure to copy examples/nw.ini.cnv.min to /etc/nwserv.cnv according to option 50 in nw.ini. This is very important, as this is used on every filename read to translate filenames. I'm not sure what happens if you forget to copy this (or forget to uncomment option 50), so do it anyhow. There are a couple other .cnv files in the examples directory, but they appear to be there for Russian language support or strange things like that.

Since I was overwriting a previous installation of Mars-NWE (from the RPM) with this recompiled version, I had to run make install_ini rather than just make install, so that it would overwrite the previous configuration file.

When I finally started the mars-nwe (by typing /etc/rc.d/init.d/mars-nwe start, but you could also type nwserv - it just won't handle proper PID locking), our real Netware servers began complaining with the following message:

At first glance, I thought that mars-nwe was using the wrong node number (I had this set to auto in nwserv.conf, by putting a 1 in section 3), but when I changed it to 0x0000000D and restarted, our other servers still threw a fit. When I typed slist from the Mars-NWE server (I had to install ncpfs for this), it did reflect the new node number, 0x0D (it also did not show any of the other Netware servers on our network). However, I went to a DOS workstation and typed slist there as well, which listed our real Netware servers as having node number 1. Oops, that's what the Mars-NWE server already had! So, it wasn't the node number as I had assumed.

I don't know why I didn't check the Network number in the first place - I guess I had missed it when I was looking through the nwserv.conf. Anyhow, it's the second option in section 4. I changed it from 0x1 to 0xD and typed /etc/rc.d/init.d/mars-nwe restart. Suddenly all three servers, both real and emulated, showed up when you typed slist from either the Mars-NWE computer of a DOS workstation. That's when a big smile came to my face. ;)

When you run Mars-NWE for the first time, it encrypts and stores the Supervisor password. Once it's stored, you should remove the clear-text password from nwserv.conf (section 12). Simply delete the password portion, as the clear-text version is not used anymore beyond this point. Do NOT replace it with a dash, as this will disable the supervisor login completely. Be sure to remove it from nw.ini (in the original compilation directory) as well.

Also, even though the Mars-NWE installation creates a startup script for you (/etc/rc.d/init.d/mars-nwe), it does not add it to the startup. So be sure to do that manually if you want it to start with your computer. Since I'm starting up in runlevel 3, I added a symbolic link to the rc3.d directory by typing the following: ln -sv /etc/rc.d/init.d/mars-nwe /etc/rc.d/rc3.d/S11mars-nwe, which runs it right after all the other networking stuff (which was at S08 - S10).

A side note - contrary to what it says in the Mars-NWE FAQ, you do NOT need an IP address on the network interface in order to run Mars-NWE on it. Of course, I have not tested it with more than one NIC, but I'm running it just fine with one NIC and no IP address.

Also, when you are logged into the Mars-NWE server from a workstation, and you type whoami, it normally displays "Netware 3.12" or whatever version the server is running. Mars-NWE, however, only displays the revision date (such as "25-Apr-00"). I want the uneducated user to think this is an actual Netware server, so I replaced this by editing nwbind.c and changing the line, #define REVISION_DATE "25-Apr-00" to #define REVISION_DATE "Netware Em3.12". Then I recompiled by typing make and make install again. Much better.

Something you need to be aware of is how rights are assigned - specifically, Linux rights vs. Netware rights. If you have all of your volumes defined in nwserv.conf with the "t" option, then the mapped user must first and foremost have rights in Linux, and on top of that, must have rights in Netware. If either is missing, they won't be able to access the file. Make sure that you have the UMASKDIR and UMASKFILE set correctly in section 1 of nwserv.conf, so that any time you create a directory or file from a Netware client, it creates it with adequate rights in the Linux filesystem. Then assign (or make sure they are inherited correctly) rights in Netware (using the rights command, of course) on top of that.

Also, if you notice that when you mkdir a directory on a Mars-NWE volume through the DOS client, the directory is created on the Linux filesystem (when you ls from the actual server) but does not show up when you type dir from the DOS client, make sure that each volume in section 1 of nwserv.conf has either the i or the k flag set! I did not have this originally on one of the volumes, and when I created a directory on that volume, it would show up on the linux filesystem in all lowercase letters. However, when Idid a dir, it only showed files or directories that were all uppercase (which is how the real Netware 4.1 and earlier saves all file and directory names). Thus, nothing was showing up even though the directories were there and all access rights were correct. First I tried adding the k option to that volume, which worked just fine, except everything was saved in all lowercase names. Because the real Netware does all uppercase, and I wanted to be consistent, I turned on the i option instead, which allows a mixture of cases. Because we are upgrading our real Netware server to Netware 6.5 in a couple months anyhow, which allows both long filenames and a mixture of upper/lowercase, everything wil be consistent. Now everything shows up just fine, and with whatever case I decide to type in.

Update: 8/11/2003

Soon after I put the Mars-NWE server online, many people trying to login to our main Netware server (an actual Netware 4.1 server) got an access denied error once they booted up and tried running login from the f:\login\ directory. It quickly became apparent that netx.exe (or VLM, if you use that - but I'm not sure that VLM supports bindery anyhow, so this might not apply to those people) had found the Mars-NWE server rather than our main Netware server.

In Mars-NWE, once a user connects to the server and before they log in, they are actually logged in with the guest account and restricted to the \login\ directory (This is the same with real Netware, except I think the account is called NOT-LOGGED-IN (but don't quote me on that. It might still be called guest!)). Since in section 13 of nwserv.conf I had the GUEST account mapped to Linux' nobody account, which effectively has only read rights to the directories concerned, the user is unable to execute login.exe from that directory. I briefly considered giving execute rights to the login.exe program, so that a user could login to our main Netware server by running login from the Mars-NWE server. Although this should work, there are several reasons why it is not recommended, the least of which is that I don't consider Mars-NWE to be extremely secure and don't want users ending up on that server every time they boot up their DOS workstation.

Update: 8/13/2003

Some computers logged into the Mars-NWE server (or with a drive mapped to it) seemed to be disconnecting after a relatively short amount of time. This did not seem to happen on Windows clients, but did happen in DOS with NETX. I could not find a setting similar to Netware's "Delay before first watchdog packet," so instead, I set Section 310 to negative one (which looks like this: 310 -1), which tells Mars-NWE to send no watchdogs at all. Therefore, a user is never automatically logged off no matter how long they sit idle.

Update: 8/19/2003

One very important thing that took me a little while to discover - if a Mars-NWE volume has the trustees flag set (which gives it trustee rights + Linux rights), the trustee assignments can add rights on top of Linux rights, but cannot take them away! For the life of me I could not understand why none of my trustee assignments for the SYS: directory were taking effect. After I reduced the actual Linux rights.. presto! Some trustee assignments also did not seem to work correctly unless the Execute right was set in Linux. So if stuff doesn't show up when it should, etc., check that! This also seemed to allow user accounts changedir into directories that they had no access to, which is an obvious security hole. But Mars-NWE seems to have quite a few of those. :( Read here for more detailed info on trustees.

Also, please be aware that when you change a user's rights for a directory while they are inside of that directory, those changes do not take effect until they leave the directory and cd to it once again! There is also sometimes a moment delay before rights take effect. Hell, please be aware that assigning trustees is all f*cked up in Mars_NWE, period! It has bugs. Good luck. :P

More to come...