Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Networking (Apple) Businesses Apple Hardware

Prosoft Releases Mac OS X Client for Netware 41

JSherman writes "Prosoft Engineering has released a client that enables Mac OS X to connect to a Novell network. The client is pure TCP/IP, and is not tied with AppleTalk. Its been possible for Macs to connect to Netware Servers for a long time by using Novell's Native File Access, but this is a much better method since it's an actual client that will remember your user ID and password when connecting to servers, and it allows you to browse the NDS tree. This is great news for all of us that use Apple computers in the Enterprise. Mac OS X progress marches on."
This discussion has been archived. No new comments can be posted.

Prosoft Releases Mac OS X Client for Netware

Comments Filter:
  • Head spins...

    They meant to say "Netware Client for MacOS", and not the other way around...
  • How is this news? (Score:3, Interesting)

    by Auckerman ( 223266 ) on Monday August 19, 2002 @02:50PM (#4099789)
    MacOS 10 has had support for LDAP and NIS. 10.2 will have support for Active Directory. Now explain to me why I should PAY for a Novell client, when all I have to do is read some documentation.
    • What's the point of automatic transmission when all I have to do for manual is press the clutch and shift gears?

      Some people don't have the time, patience, and/or skill to implement stuff like netware themselves in a convenient manner. What do you think about GUI wrappers for things that can be done in the CLI?

      If you don't see the use of this, you aren't looking beyond your world, IMO.
      • "Some people don't have the time, patience, and/or skill to implement stuff like netware themselves in a convenient manner."


        Then they should NOT be an admin. Lazy admins are the reason why many networks are insecure. This is not to be construed as an arguement against GUI's, which have their place, but merely an arguement that reading documentation to learn how to do something is what an admin is supposed to do.

        • Lazy admins are the reason why many networks are insecure.

          The Prosoft client is not for Mac sysadmins. This client is for Mac end-users in a corporate environment that only has MCSEs and maybe one old Netware guy. Folks who would otherwise be excluded from Netware servers because no one is willing to help get them connected.

          That said, the Prosoft client is a bad choice for most situations. It's $149 per client, which rapidly exceeds the cost of buying Novell 6 with Native File Access (aka No Client Needed).

          Auckerman, where exactly would I find the documentation that teaches me the Netware protocols, and how to convince 10.2 to use them directly? Right now I use FTP.

        • Some places aren't big enough or wealthy enough to hire the best admin or even a full-time admin for their network. We all know that lots of networks are insecure and a lot of admins don't cut it, right? What do you think has a better chance of happening at this point:

          1. All admins get their act together, and those who shouldn't be admins stop all activity, and small businesses that need new admins pool their funds and get one.

          2. Programs with a more intuitive and user-friendly interface come about, making it easier for any person faced with the duty of setting up network stuff to at least have a basic setup without security holes.

    • Re:How is this news? (Score:5, Informative)

      by AndyDeck ( 29830 ) on Monday August 19, 2002 @02:59PM (#4099870) Homepage Journal
      The news is that this is (reportedly) a native NCP client. LDAP/NIS/AD are all directory services - NCP is a file access protocol. Totally different animals.

      This client is intended to permit a Mac user to map directly to a Netware volume without the old Netware (or Prosoft) for MAC NLMs, and without the new Native File Access pack NLMs - both of which, in different ways, forced the Netware server to look like a Mac server. A native NCP client goes the other way - it permits the Mac to use the Netware resources natively.

      The advantage to the native Mac client is one less layer of indirection when accessing Netware-served files. The benefits should include improved security (relative to the Nw4Mac/NFAP methods), theoretically improved performance, better support for features such as clustering, etc.

      In my opinion, Novell would be better off releasing sufficient information about NCP for third parties to create their own clients if they do not intend to write their own. I'm still waiting for the Linux equivalent to this client to appear, for instance. (as far as I can tell, ncpfs only supports IPX not native IP)
      • Maybe it suprises you, but the documentation for NCP is public already for a couple of years : http://developer.novell.com/ndk/doc/ncp/ncp__enu/d ata/hc4lztgy.html Also, current versions of NCPFS do support NCP/IP connections.
        • I stand corrected, on both counts. The latest versions of ncpfs do indeed have support for NCP over IP.

          I actually did know about the NCP documentation [novell.com] available through Novell's Developer Net - it's not what I originally had in mind though. Yes, it does document each NCP call - but (IMO) it hardly gives enough information to be used to generate a new client. Perhaps I'm just not enough of a developer to appreciate what's in the document.

          The information is also provided under a restrictive license agreement that could inhibit its use for creating 3rd party Netware clients:
          2. You may use the NCP Documentation only for providing technical

          support services to end users of Novell products and to support Your
          development of Derivative Software that does not: a) enable more than
          one end user per copy of the Derivative Software to access a NetWare
          server; or, b) provide NetWare server functions.

          I can see where they are coming from... and given that ncpfs does now have the necessary IP support, and Novell has even gone so far as to donate some time from one of their engineers to improving Ethereal's [ethereal.com] NCP decoder, I don't really have any objections.
          • 2. You may use the NCP Documentation only for providing technical support services to end users of Novell products and to support Your development of Derivative Software that does not: a) enable more than one end user per copy of the Derivative Software to access a NetWare server; or, b) provide NetWare server functions. Actually, I read this as client software development being allowed using this documentation. What is not allowed is using to documentation to write some kind of gateway that would allow multiple users to connect to the server over a single connection, thus bypassing the server licensing, plus the implementation of an NCP server.
            • Sorry, looks like the formatting did not turn out the way I intended it.
            • >cimetmc said:
              >Actually, I read this as client software development being allowed using this documentation. What is not allowed is using to documentation to write some kind of gateway that would allow multiple users to connect to the server over a single connection, thus bypassing the server licensing, plus the implementation of an NCP server.

              Yes, that is the strict interpretation... but remember, lawyers interpret licenses, not people. The license does permit client development given the above two restrictions - but those are enough to (IMO, IANAL, etc) prohibit this documentation's use to create GPL'd software.
              I just checked, and 1) ncpfs IS GPL'd, and 2) the author does not seem to have used Novell's documentation in the development of ncpfs. Why? Because ncpfs will permit you to mount a Netware volume at an arbitrary Linux mount point, and permit any Linux user to use files on that volume. This explicitly violates the NCP Documentation license at 2a.
              And this is what I had in mind when I suggested that Novell would be better off making client documentation freely available - but as I said in my last message, the fact that ncpfs exists, is GPL'd, and contains IP support satisfies my needs. But this was only possible through the use of third party documentation (including some of Caldera's work), reverse engineering, and (in the USA) the expiration of the RSA patents...
              As for the relevance of this all to this story, ncpfs can't be used on older Mac's, although it could conceivably be ported to OSX. Hence the importance of Prosoft finally updating their client to support modern (IP-only) Netware servers. The rub of course is that the new client is OSX only, so older Macs are stuck with IPX (old Prosoft client), Appletalk (NW4Mac on NW4 or Prosoft NLMs on NW5), or NFAP on NW5.1 or NW6.
  • Platform potpourri (Score:3, Informative)

    by Mr.Intel ( 165870 ) <mrintel173@NOSpam.yahoo.com> on Monday August 19, 2002 @02:55PM (#4099825) Homepage Journal
    Not only can you get a NetWare client for the MAC (OS X) but you can download the demo from an ASP [prosofteng.com] page. For those who don't want to bother with the reg info, here is the link [prosofteng.com] to download it directly. The serial they gave me was 9602-3082-0060-5950-2. I assume it is time limited or some such other nonsense.
  • At least, that's what Novell and the reviewers say.
    • This is true, if you use the Native File Access Pack, is included free with NW6. However, as I noted in a previous message [slashdot.org], the NFAP is an additional protocol layer, similar in function to Samba. It re-exports native Netware volumes over alternate protocols - CIFS (Windows), NFS (*ix), and AFP (Mac) - all over IP.

      The biggest difference for me is security & passwords, but then I'm a directory services geek. NFAP authentication by design uses a separate password hash than NCP authentication. A native NCP client uses RSA-licenses public/private key encryption to protect passwords - CIFS, AFP, and NFS do not. Therefore NFAP is designed to have a separate password for these protocols to protect the native password. The NFAP password is usually still protected by some kind of hash algorithm, but this is not as secure as the NCP methods.

      But one of Novell's latest mantras is anywhere anytime access to your data, so they include NFAP as a least-common-denominator.
  • This is nothing new. I have been using this client for almost a month now, with limited success. It is VERY buggy, but it beats having to rely on ftp or booting into OS 9.

    To the people making fun of novell users -I don't use novell by choice. I hate our university's network. I wish our departmental IT guy would dump that stupid novell server, but he's always raving about it for some reason. And I still can't figure out how to configure the #@%^! OS X Cisco VPN client so I can login from home. Thanks to the total lack of support for anything besides windoze, I probably never will. Hmph.

    -margaret

To the landlord belongs the doorknobs.

Working...