How can I improve my support of Novell networks when I don't have a Novell network?

Question

I work for a .NET/MSSQL shop that has trouble supporting customers running Novell, partially because we don't have Novell (or the money for it) and partially because we have no one with Novell experience. This question could easily be expanded to "How can we improve our support of technology X when we don't have technology X?" Obviously, I expect someone to say "it is easy to acquire the technology or someone with that kind of experience," but keep in mind I'm just a developer, not the development manager or someone with power over the purse strings. I looked for a Novell server virtual appliance (though I'm not sure "Novell server" is what I should be looking for) but didn't find much on VMware's website.

Answer 1

There used to be some relatively cheap developers network which we used to belong to before the Novell questions all whithered and died away (famous last words, now I bet we will get one tomorrow), there is never any substitute for having the software / hardware, the only alternative is to write a test program and get your user to run it. I am intrigued though as to what problem you are getting, the main ones we got were file locks with Jet databases.

Answer 2

When you say running Novell, you need to consider what that means.

Most likely you mean either uses Netware servers, or use eDirectory for authentication.

With the release of Open Enterprise Server, Novell ported the core functionality of most of the Netware stack to run on SLES (SUSE Linux Enterprise Server). Thus OES runs on a Netware or Linux kernel. Services are much the same on both (there are some subtle differences that are probably outside the scope of this issue).

If you mean Netware servers (or even OES Linux servers providing file shares) then it becomes an issue of how you access the file system. If it is simple reads and writes from a network drive, then there are two approaches.

1) Install the Novell Client on the box that needs the file system access so it can make an NCP (Novell Core Protocols) connection to volumes and data hosted there.

2) Get the Novell server admin to enable CIFS/Samba (On Netware kernels, it is CIFS a not-ported-from-Samba implementation of CIFS. On OES Linux it is currently Samba using eDirectory for credentails. On the soon to be released OES 2 Sp1, on the Linux kernel, the Netware CIFS stack has been ported to Linux since it is much more performant and scalable, when compared to just Samba) on the server.

More likely however you mean eDirectory is used for Authentication. If that is the case, just pretend it is an LDAP directory and you should be pretty much fine.

eDirectory is cross platform, and runs on Windows, Netware, Linux (SLES and Red Hat at least), Solaris, AIX, and HPUX. It is practically indistinguishable which platform it is running on, so whatever you have in house expertise on the core OS, install an eDirectory instance on it, set up a test tree, and you can test your authentication code against it fairly easily.

There should be a free 250,000 user license available for just eDirectory for Developers still. (In fact I do not think they even bother asking for licenses for just eDirectory. The add on products require licensing. OES requires a license to access file shares or shared printers. Identity Manager (IDM) is bundled with almost any other Novell product license, but only for use with the bundled drivers (AD, eDir, Notes, Exchange) the rest require licensing.

Hope that helps. If you are looking for pointers and beginners guides, there is a huge amount of content at Novell Cool Solutions.

If you have a specific problem let me know and I will see if I can help out.

Answer 3

There is a 60 day evaluation trial of Open Enterprise Server 2 available (requires free registration). If you install it in a VM, there's nothing stopping you from reinstalling it after 60 days (well except licence).

But you will need someone good with Linux to handle this (and preferably good with this precise technology). In a MS shop this might be a problem.

The easiest solution would be to outsource this - have some external techs test your software for compatibility. If you find out you are paying too much - hire someone who knows this software stack.

You can't support something if you don't test against it. And you can't test against something you don't know.