Introduction
Kanaka is a product of Condrey Consulting Corp, who provides support via their website (http://www.condreyconsulting.com). There is a good forum area where the author responds to most posts fairly quickly.
As promised, Condrey Corporation today released Kanaka for Mac 2.1—the first version of Kanaka with no NetWare dependencies. With Kanaka 2.1, you can host the Kanaka Engine on a Novell OES2 server, a Microsoft Windows Server 2008, or Microsoft Windows 7 workstation. Kanaka, Two items I would check. Is the file empty? Our install -rw-rw-r-- 1 root netreg 174439 Jul 26 09:02 netreg.registered >From the install PDF. If this is your first visit, be sure to check out the FAQ by clicking the link above. You will have to login before you can post: click the LOGIN link at the top of this page to proceed.
Assuming you are familiar with Kanaka and how it works (if not, see my previous Cool Solutions article), you'll see that there are several areas where problems can occur. The single biggest problem is that the Open Directory (OD) interface to the Login box, provided by Apple, does not allow a plug-in to return error messages. All you get are the Apple defaults, which are quite minimal, and that is it.
Thus, the Kanaka OD plugin cannot return useful messages because of an Apple limitation. This is frustrating. But the the server-side components give two places to watch for errors: the KanakSC.nlm screen on the server console, and the KanakaSC web interface via Novell Remote Manager (NoRM) at https://server.ip.address:8009/.
Monitoring Errors
To use a web browser to monitor both places where you're likely to see Kanaka errors,
Kanaka Client For Mac Error Result = 100 10
1. Connect to NoRM.
2. From the left hand column, select Console Screens and pick the KanakaSC screen to watch. If your browser supports Java, you get a web page with a Java applet showing real time updates. This allows you to see login events as they happen. If not you can use the simple HTML versions but you will have to refresh manually.
3. In the first window, select Kanaka from the bottom of the left side list and select User Access Requests. This shows the version of the OS, the version of the Kanaka OD plugin, IP address, user name, activity, error/success, and the home directory path returned.
FileZilla is a popular free FTP client for Windows, Mac, and Linux. It is perhaps, the most easy to use FTP client. However, the reason we have placed it on the fifth position is because Windows users have reportedly found adware or spyware packaged into FileZilla downloads. Read the latest review of the Top Mac FTP Clients 2017-2018. Evaluate and choose the best FTP client for your own needs. We gathered a short overview of the top FTP client solutions for macOS and hope it will help you to find the best FTP manager for you. Top FTP Clients For Mac 2017-2018. Top choice Commander One 4.5 Rank based on 89. Ftp client for mac reviews. Brew cask installs macOS apps, fonts and plugins and other non-open source software. $ brew cask install firefox Making a cask is as simple as creating a formula. These similarly named formulae were found: bbftp-client curlftpfs git-ftp lftp ncftp proftpd pure-ftpd swiftplate uberftp uftp vsftpd To install one of them, run (for example): brew install bbftp-client ==> Searching taps. ==> Searching taps on GitHub. Aug 07, 2018 Mac command line users may have noticed that FTP is missing from the latest versions of MacOS system software, but despite ftp not being included in newer versions of system software by default, you can still install ftp on Mac OS if you need to use an ftp client or run an ftpd server for whatever reason.
Using these two tools you can diagnose the majority of problems that will occur.
Types of Problems
Because Kanaka logs the user in over HTTPS, it uses the eDirectory password (RSA, Simple, or Universal) directly for the first connection attempt. Then it attempts an AFP or SMB login to mount file space, using either Simple Password or Universal Password, depending on your tree configuration.
There are four basic problem types:
- Kanaka connectivity
- Password problems
- AFP/SMB connectivity problems
- Kanaka interactions with AFP/SMB
Kanaka Connectivity
In the Directory Access tool, when you choose to configure Kanaka, there is a link to allow you specify a URL to download the latest client. This is an almost identical URL to the one needed to configure Kanaka for connectivity. If you choose to use this link, and try and download the file from the Kanaka server, then it validates if the host can resolve the address, make the HTTP or HTTPS connection, authenticate, and other communication related issues.
It is rare to see issues in this area beyond typos in the URL.
Password Problems
This is a complex issue, and assumes you have some understanding of how passwords work with Native File Access in Netware 5.x and higher. Basically, the problem is that the NDS password, known as RSA password, is stored as a public key/private key pair, that is not reversible. In other words, if you were sitting with the contents of both keys, there is no mathematical way to get the clear text of the password back from them. (If you can, sell it for LOTS of money, or blackmail everyone who relies on this fundamental feature of RSA encryption).
Kanaka Client For Mac Error Result = 128
SMB uses a password hash function called MD4, which takes the password the user provides, uses a set of rules to turn it into something gobbledygook-looking, and stores the result. So every time you connect, you re-run the gobbledygook-izer and send the result to be tested for a match. This can be broken with brute force methods, since by design the hash method is pretty quick.
NFS uses a similar idea but a different hash algorithm, called MD5.
AFP uses yet another method called two-way random number hashing, by default. In a nutshell, the server needs to have a copy of the password in a format it can retrieve as the password.
Here we have four authentication methods - Novell, Microsoft, Unixes worldwide, and Apple - that all need different password requirements stored on the server, none of which are really directly compatible. Novell's first attempt to resolve this (in Netware 5.0 to Netware 6.0) was with Simple Password (SP), which gave eDirectory the ability to store the password several times, and made some attempt at keeping it in sync with the RSA passwords. There are all sorts of issues and workarounds required with Simple Password.
With Netware 6.5, and thus OES and higher, Novell added a new feature called Universal Password (UP) which is much better and allows eDirectory to store the password encrypted, but retrievable. With Universal Password many of the problems of Simple password went away, and it is much better at keeping the RSA password in sync. In fact with UP, you can turn OFF the RSA password and only allow authentication via UP. (It does require a later Client32 to work, but it does work.)
Note that SMB server-side modules, AFP server-side modules, NFS server-side modules, LDAP, etc. are UP-enabled. When a UP-enabled client connects, it sends the appropriate response, and the server is able to handle it from a single instance of the password stored securely.
If you do not have either SP or UP working properly, you will not be able to authenticate to AFP or SMB to mount a home directory. So get your house in order .. Fixing all of that is outside the scope of this article, but testing is easy.
- Test the eDirectory default password (usually RSA, but with the advent of UP, an admin could have disabled RSA completely) by logging into NoRM with the specified account.
- Test the AFP/SMB password by connecting to the server via Apple-K or Connect to Server from the Finders Go menu (Check for menu name accuracy).
If either of these fail, then the problem is pre-existing, and Kanaka cannot be expected to work.
AFP/SMB Problems
Technically, the last test above (AFP/SMB password connectivity) also should be included in this item. Assuming you get AFP connections working, at least to login and mount a volume, now you need to confirm you can mount the correct volume for the user who is experiencing problems.
AFP Server side Problems
Native File Access, which provides the AFP stack on Netware, uses several control files on the SYS of each server running it:
- SYS:ETCCTXS.CFG
- SYS:ETCAFPVOL.CFG
- SYS:SYSTEMAFPSTRT.NCF
CTXS.CFG lists the contexts in order that AFP searches when it logs in a user. It will use the first occurance of a user name. So if you have a BobSmith.A.B.C in your tree, and a BobSmith.B.B.C (which is valid), and you are searching both in the CTXS.CFG file, then only the first one listed will work. If a user exists in a container outside this list, they will not succeed in logging in over AFP.
AFPVOL.CFG lists the names of the volumes on the current server, and any aliases you made to pretty them up. By default, the Users volume on ServerA is shown as SERVERA.USERS to AFP logins. You might choose to use AFPVOL.CFG to remap the name to something prettier like 'Users'.
Take care, because this file is VERY sensitive to spacing and tabbing (do not use tabs). It can be difficult to fix things there; once it is set, the info is stored somewhere in NSS, and you need exact spelling to fix it after. If all else fails, you can unload AFPTCP.NLM and reload it with the command line-switch 'LOAD AFPTCP RenameFromNWVol'. This will reset the value so you can use AFPVOL.CFG again to change it. (Unload with AFPSTOP.NCF and reload with your usual AFPSTRT.NCF if you use any switches in AFPSTRT.NCF.)
Clustered volumes must use this file. On ClusterNodeA, it will appear to Mac users as CLUSTERNODEA.USERS, and on ClusterNodeB, it will appear as CLUSTERNODEB.USERS, which will cause problems. Instead, read the documentation inside the comments in the AFPVOL.CFG file, and rename the volume to something nice like 'Users' on all nodes.
AFPSTRT.NCF is the file that is used from AUTOEXEC.NCF to load AFPTCP.NLM and NFAP4NRM.NLM (the NoRM plugin for Native File Access). Edit this file and place any runtime switches you have determined you need for AFPTCP.NLM. The list is at http://support.novell.com/cgi-bin/search/searchtid.cgi?10072783.htm
Kanaka Interactions
Once you have cleared up the connectivity, password, and AFP connectivity issues, you can start looking at how these interact with Kanaka.
Kanaka maintains a list of contexts to check for its login contextlessly, although it periodically builds an index it consults internally before walking the tree. If its list does not match the CTXS.CFG list, then odd things can occur. If the contexts do not match, only one of the two authentications might work. (If a user is not found in the index, perhaps because the user was created as an account after the last run of the index dredger, Kanaka will then walk the tree looking for it, adding it to the index).
Watching in both the Console screen and User Access Requests screen from NoRM, try a login and see if it succeeds. If it fails, the most common cause is complaining about not being able to mount an AFP or SMB home directory.
There are several possibilities at this point. The web interface should show a successful authentication, as well as a returned home directory value.
Troubleshooting Steps
1. Make sure the actual home directory matches in AFP.
AFP in NetWare 6.5 is case-sensitive. Niviab5 minecraft client for mac. As of SP3 (or OES NetWare) there is a way to enable case-insensitive but case-storing AFP. At the server console you have to add the Extended Mac Namespace to each volume (NSS /ExtendedMac=VOLUME and AFPNames case-insensitive volume_name) to enable case-insensitivity.
Alas, it appears at this time that while third-party tools like JRB's VOLINFO (http://www.jrbsoftware.com) can determine if the volume has the Extended Mac Namespace on or not, it is not yet possible at this time to report if the volume is set to case-sensitive or case-insensitive.
If you cannot make the volumes case insensitive, then the value in the eDirectory HOME_DIRECTORY property of the user must exactly match the case in the file system.
2. Make sure the mapping of volumes AFP names to eDirectory names in Kanaka is done correctly, and with case-sensitivity in mind.
'Users' is different from 'users' or 'USERS', to case-sensitive AFP. The NoRM > Kanaka > Global Volume List will show the current values, so make sure they are what you expect and correct. For this problem, press Apple-K to connect to a server as afp://server.ip.address/ - this will show what the server is presenting, as it lists all available volumes with the exact syntax you need.
3. If the path shown in the NoRM > Kanaka > User Access Requests screen is the server running KanakaSC's SYS volume, and a Proxy directory, read the name of the proxy dir (ERORRREADINGHD, NOUSERHD, USERHDNOTONDISK) and resolve the problems accordingly. Again, an Apple-K connection will at least mount the volume, even if they do not have a home directory (deleted) or a value in the attribute set.
4. If a Proxy directory is being returned as the path, the user on the Macintosh may not see that; instead, they will get the 'unable to mount an AFP or SMB home directory' error.
This happens if the server with the Proxy directories cannot allow AFP connections for all users (because AFP on Netware requires that the authenticating user's object be found in a local replica, and you may not have all the replicas on this server). See my article on Kanaka for a cute workaround to this problem.
Conclusion
That should cover the most common problems found with Kanaka. If you find that none of these solutions work for your problem, post in the forums on http://support.condreyconsulting.com and the author will often respond.
Universal Binary support is apparently ready, the last I heard, but not yet released. OS X support is up to 10.4.5 at the time of this writing.