iPrint is the Web interface, client, and IPP support in NDPS, renamed. Also, iPrint on OES Linux only supports the iPrint client, not the NDPS Client (part of Client32) and the iPrint protocol with is IPP and HTTP (combined with SSL for IPPS and HTTPS). The NDPS Client uses RPC’s (Remote Procedure Calls) over NCP, which is not supported on OES Linux.
It is probably a good idea to get an IP address assigned to your iPrint service, since you can move it via a cluster, or even in case of a server failure. If all your users install printers that point at a service address (like iprint.yournetwork.com) instead of a server address (serverA.yournetwork.com), when you move it around, your clients will not need to reinstall the printer. If the IP of the service changes, then the printers look like new printers.
You can assign it as a Secondary IP address. At the console type:
add secondary ipaddress 10.0.0.5
Or add it to your NCF files.
Things to confirm it’s running:
The command line options needed are a bit much, so we use a NCF file to make it easier to do it correctly.
NDPSUP.NCF is run from the AUTOEXEC.NCF to load all the NDPS/iPrint modules
and commands, pasted below:
#Add iprint.yournetwork.com as a secondary IP, that we can move if we need to later. add secondary ipaddress 10.0.0.5 #Load NDPS stuff, broker and manager. load broker .your-broker.servers.yourO # Bind to the secondary IP address, and set its IP Name load ndpsm .your-ndpsm.servers.yourO /DNSNAME=iprint.yournetwork.com
So confirm it worked, at the console by:
(You can use MODULES or M, since M is aliased to MODULES on NW6 and
higher, type ALIAS to see the list of aliases)
MODULES BROKER (To confirm BROKER is loaded)
MODULES NDPSM (To confirm NDPSM is loaded)
DISPLAY SECONDARY IPADDRESS (to show the iprint.yournetwork.com address is
Then make sure Apache2 is loaded with the mod_ipp loaded.
Look for an Apache2 screen which lists ports as 80, 443, and 631. That is
the instance running iPrint (631 is IPP over SSL)
AP2WEBUP and AP2WEBDN load and unload this Apache2 instance.
LDAP Config issues:
iPrint’s Apache2 config is in SERVERA\SYS:\APACHE2\IPRINT\ipp.conf and there
is a line:
This tells you how (LDAP or LDAPS), Which server (yourLDAPServer), where in the tree
(O=yourO and down) the search for users is performed.
This can be problematic if your tree setup is not conducive to this – for example, if you want to search 3 out of 5 containers under the your O container. A couple of possible solutions exist:
- Run an iPrint instance on a different server for each OU under your O.
- If this does not conflict with any other LDAP app, only populate the UniqueID attribute on the users in the containers you care about. This may not scale well, but is how we do it currently). You need to be careful, since other LDAP applications may want a UniqueID value. Also, ConsoleOne and iManager automatically add the UniqueID with the same value as CN when you create an object. NWAdmin does not.
- You can map LDAP UID to eDirectory CN if you do not have or want to populate the UniqueID on all your objects. Then if you carefully place your replicas on an LDAP server, set it not to dereference queries if it not found locally, and try to restrict the scope of the search to the containers you are interested in.
How to Trace LDAP Problems (DSTrace):
Go to yourLDAPServer.yournetwork.com in Rconsole/RconIP/Afreecon or whatever tool you like. You can use iMonitor as well (https://yourLDAPserver.yournetwork.com:8009/nds). In our case, we happen to point at a cluster resource, which has LDAP loaded. So you need to figure out which node, since it is pointed at the cluster resource, not the server) and watch in DSTRACE:
DSTRACE SCREEN ON
DSTRACE -ALL +LDAP
Try to login with the iPrint client and look at the search, and the results.
Correct Search and Response:
A valid search and response looks as follows:
DoSearch on connection 0x81a76980 Search request: base: "O=yourO" scope:2 derefence:3 sizelimit:0 timelimit:0 attrsonly:0 filter: "(&(objectClass=user)(uid=ykufac))" Sending search result entry "cn=Ykufac,ou=fac,o=yorkO" to connection 0x81a76980
It searched from a base container of your O down, with a scope of 2 which means search all containers under the specified container.
With no size or time limits (0 means infinite) with a filter on Object Class of User (Only users are interesting to us here) AND a uid value of ykufac.
Because this is an AND, it has to match both criteria. And it found a single result and returns the DN (Full location in the tree) of ykufac.fac.yourO (but in LDAP speak).
Multiple value response:
If you see multiple values returned, then we have a problem. iPrint only
works if the user exists in one context. If they have a another account in the search scope of the tree, they will have an issue.
You can fix this by setting the UniqueID attrib on all
accounts you care about by using JRB’s Setname /a=UniqueID and feeding it a file with a
list of NDS names, and CN’s. (e.g. TestUser.fac.yorkO TestUser).
Or you can get your provisioning system to add this attribute, or you can generate an LDIF file to add it to all objects.
DoSearch on connection 0x81a76980 Search request: base: "O=yourO" scope:2 derefence:3 sizelimit:0 timelimit:0 attrsonly:0 filter: "(&(objectClass=user)(uid=TestUser))" Sending search result entry "cn=TestUser,ou=fac,o=yourO" to connection 0x81a76980 Sending search result entry "cn=TestUser,ou=ssb,o=yourO" to connection 0x81a76980 Sending search result entry "cn=TestUser,ou=gis,o=yourO" to connection 0x81a76980 Sending operation result 0:"":"" to connection 0x81a76980
Here we see it has found three instances of the username TestUser, which is an LDAP error, since it is searching on uid (which maps to eDirectory’s UniqueID attribute), which is
by definition “unique”. If it finds more than one, that is an error.
No Value returned:
If you see the search and no value returned, make sure the user exists where
If you see a -217 error in the DSTRACE, it is a Concurrent Connection count
exceeded error. I cannot figure out what/why to change… To fix, unload NLDAP
and reload NLDAP on whatever node has yourLDAPServer, at the moment.
This has been seen at other sites, but seems to come and go. For at least one other site, updating to eDir 184.108.40.206 helped.
If you see a -306 error, Invalid Syntax, then the uid <=> UniqueID mapping wrong.
Search request: base: "O=yourO" scope:2 derefence:3 sizelimit:0 timelimit:0 attrsonly:0 filter: "(&(objectClass=user)(uid=TestUser))" Invalid integer syntax:"TestUser" nds_back_search: ldap2NDSSearchFilter failed with err -306 Sending operation result 21:"":"NDS error: -306 (0xfffffece)" to connection 0x8830b9e0
To fix it, in ConsoleOne go to the context of the server used for LDAP, to the LDAP Group Object, to the Attribute Mapping page, and set a mapping of NDS UniqueID to LDAP uid and LDAP uniqueID.
You can also search to see if there are any other mappings affecting these attributes. Because an attribute can have a primary and secondary mapping, sometimes the attribute appears hidden to casual inspection.
If you see no error in the DSTRACE screen, we need to check the Apache2 logs for errors.
Apache2 Logs are at:
Sort by date and read newest logs. (errors_log.timestamp)
Example Apache Log errors:
No LDAP over SSL error:
[Fri Sep 03 12:28:37 2004] [warn] [client 10.0.0.9]  auth_ldap
authenticate: user TestUser authentication failed; URI /ipps/pa-parking [LDAP:
ssl connections not supported][Unknown error]
In this case, ServerA could not make an LDAP over SSL connection to the LDAP
server. Fixed by editing the AuthLDAPURL line (see above in ipp.conf) to say ldap:// instead of
ldaps:// Since this traffic all stays on local campus subnets, reserved for
servers, it should be OK.
No LDAP Connection:
[Fri Sep 03 12:21:26 2004] [warn] [client 10.0.0.9]  auth_ldap
authenticate: user ykufac authentication failed; URI /ipps/pa-YourPrinter [LDAP:
ldap_simple_bind_s() failed][Can’t contact LDAP server]
Not sure what caused this one, but restarting the iPrint Apache2 instance made it try and reconnect. (Might have been caused by a cluster failover that moved the resource we point at overnight).
SSL Error (unknown error), Error Group: SSL, Error: 1
Could be the URL linked to, to install the printer was created as IPP and has now changed to IPPS and requires SSL. Check the URL linked, and see if it is HTTP:// or IPP:// instead of https://. You can use http://iprint.yourNetwork.com/ipp to see the default printer list, that iPrint always builds and look at the link to see what it should be. Also, you can look at the /ipps link to see the printers requiring SSL to authenticate.
IPP over SSL:
iPrint by default seems to enable PA’s as iPrint, Low Security, and no need for SSL. This means the authentication, and content of the print job traverse the network in clear text.
This may not matter at your site internally, but since iPrint is designed to be used from outside the network as well, this can become problematic.
Additionally, and at my site, more importantly, is that unless a PA is set at High Security (Which implies requiring SSL) and SSL, you cannot restrict access to the PA.
That is, any user who can find out the URL to the iPrint PA, could install it and send a job to it. The only way that enforces authorization (i.e. TestUser can print to pa-YourPA but not pa-expensive-colour-printer) is high security with SSL. This is not obvious, nor would one assume this is required, but be careful, since it is the case.
NDPSM Health Manager:
Most people do not seem aware of it, but the NDPS/iPrint team at Novell have the most amazing support tool ever from Novell embedded in their product.
Go to Novell Remote Manager (NoRM) for your server running the NDPSM.
http://ndpsmServer.yourNetwork.com:8008, (always go to 8008, since it will automatically kick you over to 8009 and https:// if your SSL certificates are good. If it does not, then you know you have a Cert problem that you need to fix. Good habit to get into, I think).
If the node you are looking at is running the NDPSM or BROKER modules, then there will be an item Manager Health and/or Broker Health in the top list on the left hand frame.
This is an amazing troubleshooting tool that is worthy of another article in itself. The Manager Health starts by showing you the status of all the PA’s local on this NDPS Manager, nicely showing the errors all at the top. Conversely, if you are demoing this to someone, it can be embarrassing to see many printers in red, seemingly in error. Often it is just that the printer is turned off by the end user, so don’t get too worried.
Scroll to the bottom, and hit the Advanced button. This is where the really good stuff is. For each major NDPS function, there is a page showing statistics on how each function has been used, and if any took excessive amounts of time. Lots of good troubleshooting opportunities to be found here.