Mac users increasingly expect feature parity with Windows users.
I suggest that now is a good time to build an NCP client for the Mac again to include features such as login script processing, salvage etc. This could be easily ported from the current Novell Client for Linux (NCL) and the NCL could be updated to work for a wider range of Linux distributions.
Without this, Microfocus' cross-plaform story is sadly incomplete.
by: Paul R. | over a year ago | Novell Client
Comments
agree 100%. I do see MAC base is increasing and not supported well. Kan-aka engine maintenance need to be avoided or too many issues for an average admin.
NCP is the way forward.
This would make our lives so much easier. Installing Kanaka servers just to handle Novell logins for our rapidly growing Mac population is an extra management burden that I just don't want to have to deal with.
...and, of course, Kanaka isn't actually a client - it's just a shim that enhances CIFS to workaround the lack of the kind of features we would expect from a proper client. It's still buying into the story that CIFS is good enough.
Our Mac base has been increasing steadily over the years too. However, what I would personally benefit from is a fully supported Linux client. Most of the servers I am responsible for run on OES Linux. It makes sense therefore to use a workstation equivalent O/S to manage them. Being able to use JRButils in a Bash environment makes my job a lot easier and has other benefits too.
NCP is one of the "Crown Jewels" that Microfocus acquired in the Attachmate/Novell merger (along with items like FLAIM, NSS, eDirectory, etc.). It is a sophisticated, proprietary technology that Microfocus controls and can improve at-will. On July 14th at noon, I will give a presentation at the TTP Provo conference (in the Building H conference rooms) entitled "NCP: Now and Forever" making this case. However, for purposes of this "idea" I will limit myself to pointing out that NCP does a lot more than file sharing, and the basis for providing any functionality at all via NCP is to have a set of clients that can intelligently send and receive NCP packets. Having a rich OS X client is necessary to fully utilize NCP as a differentiating technology on the server side, and it can provide a host of functionality to the OS X client. It does not need to necessarily be a full login-and-map drive client, but it does need to provide both a GUI element and command-line utilities. I strongly vote "yes" on this submission.
One of the biggest issues is remote use and firewalls. I'd support this more if the proposition included tunneling 524(NCP, 427(SLP) and 636(SLDAP) over HTTPS into the Novell Client.
Since you mention the firewall issue, let me confess to what I would really like:
For the Filr client and the NCP client either co-operate or even become the same thing so that they work something like this:
1) If the workstation is online and can see the server directly over NCP then use NCP and provide all the (salvage, file-locking etc.) bells and whistles directly.
2) If the workstation is online and can see the server over https (Filr) then use that.
3) If the workstation is offline use https (filr) sync.
However, a couple of other things need to be improved to make that vision workable:
a) Login scripts and Net / Home Folders need to be unified somehow so that things look the same whichever way you connect.
b) Filr filtered sync needs to intelligently work out which network files you’re likely to need locally (eg. files opened within the last 3 months).
Also, PLEASE do not write this in Java. It will be tempting to do so since Microfocus has a lot of Java programmers, and even some NCP client code already written in Java. However, our experience has been that Java applications in general and specifically those written by Novell / Microfocus continue to act in ways alien to OS X.
MAC Client all the way!!
absoloutely, agree 100%.
Wouldn't Mono (http://www.mono-project.com/) be ideal for this? I'm not a developer but, one code base for all three, why not?
We have been running into problems using Novell CIFS time and time again on Macs, mostly due to the fact that Apple has a complete disregard for backward compatibility (and is proud about it). Novell CIFS engineers do their best to fix problems with every new Mac OS release, but this chase is impossible to win, because Apple and MSFT have partnered up lately. MicroFocus needs to control both sides of the equation (server and client) to stay on the ball in this chase (just like they do on Windows). It is not possible to guaranty results if you depend on someone else (i.e. Apple) to deliver half of the user experience for network file access (well, more then half actually). I think a Mac OS X NCP client will isolate Novell quite a bit from Apple's stance that pushing latest features for home users outweighs breaking things for Novell users.
Some random thoughts; For most linux users in NSS environments, I suspect the majority of us are Administrators who simply use scp/ftp/cifs against the NSS volumes to move files. The Novell NCP Client that was available for SLE 11 was almost acceptable, but it was always behind/breaking with routine linux patches and it is no longer available for SLE 12. I suspect the old linux NCP client was taking too much in the way of resources to actively maintain. Improved native linux NCP support would be very helpful, even if it is just for current Suse releases and even if support is only limited to improving ncpmount (for example, it could be better integrated into current Suse supported File Managers, Add a Yast NCP configuration module if necessary, etc.). Perhaps even a native Filr client for Suse linux would help most use cases as Filr seems to be the future multi-platform client, but there are limitations and it offers no where near the performance of NCP or even CIFS.
this explains why mono may not be a good idea. also there is no mono support in SLES12 or SLED12 http://www.osnews.com/story/24693/Attachmate_Lets_US_Mono_Developers_Go/
David, that Mono-relatd article was from 2011. Since that time, MS has open sourced .NET, and Mono 4 was just released in May of this year. I'm not advocating for anything based on Mono (I dislike the entire .NET paradigm, frankly), but whatever Attachmate may have done to Novell's original Mono project should have little bearing on anything at this point.
Qt might be a good choice for the GUI interface, at least, but as for the core components under the hood, I'm not familiar enough with the Mac to render an opinion. I do agree with the earlier mention of *not* doing this in Java, however.
Consolidating Client for OES Platform requests and associated client requests under https://www1.v1ideas.com/MFI/novell-oes/Idea/Detail/15373
Marking this as completed, as the alternative tag is only inappropriate, which is clearly not the case.