If you are attempting to roll a client on the Linux platform to print to a Pharos-enabled queue:
1. Create a printer connection using either lpd:// or smb:// to the Pharos server hosting the printer. The "share name" of the Pharos queue will be the LPR queue name.
Note that if you use SMB, you will most likely have to supply a valid Windows user/password. This will be saved as a clear text setting in the local system.
2. Use an appropriate driver to get the necessary output options.
You will not be able to take advantage of Pharos Popup on the Linux host, since we do not have a Linux-capable Popup client. So you queue will have to be configured in Pharos Administrator to NOT require Popup. Also, the job owner for LPD connections will be the Linux user name. This may or may not work for your particular environment.
Scott, how would you handle it if the queue to be printed to *was* requiring the popup? Create a new queue on the same device that was Linux only? And how does Pharos check that the owner printing has funds, etc. without the popup?
Does your environment use direct-print or does patrons release jobs via a Pharos station? If the Pharos station option is used, as Scott mentioned, as long as the login name on the linux system matches their "normal" username than the job will be associated with their identity when they login to the Pharos station and that manages the whole fund management issue nicely without involving popups.
Alternatively if you have the MobilePrint / Print Center Web option installed and configured you could have the linux patrons simply upload their files via a web browser and skip the printer connection issue completely.
Chris, we use the popups, no stations. Or we have direct print from specific IP ranges that operate outside Pharos and are charged by meter reads. We tried to set up Linux printing using the login name, but in our universe that's not a requirement, so in many cases not what's what. I don't want to have a host of different folk doing it differently, so for the nonce we don't support Linux.
We've been moving towards getting PrintCenter set up to use, but as I am the one who does the setup, ran into some unresolved problems, and have been weighed down by other work so have set it aside, I've not released it into the wild.
Linux is a challenge in this respect. First, your queue used by the Linux folks can't be controlled by Popup. Chris makes a great point about using PrintCenter to bypass that when MobilePrint is also licensed and installed.
We would have no way of determining if the account used for printing could support a balance unless the Linux account is represented in the Pharos database. However, if you are "direct" printing, there would be no means to feed back the system disposition if the balance is insufficient for the job.
Scott, we've found it very challenging indeed.
That's why we're going to use Print Center. Unfortunately, our first two Linux testers weren't able to use it with a Linux-created PDF; neither could get the PDF to convert properly and release (it just hung up). I'll be doing more experiments with Linux and Windows users (not as concerned about Mac, everything I've thrown at it from my test machine has done fine) after the conference. I'm interested to know if anyone else has had problems getting things to print from Linux through Print Center, though...
See you Monday!
I just fired up my REHL12 x64 workstation and was able to login to Print Center and upload a PDF from the client and release it using Print Center to my HP device. For the PDF, I used Firefox then printed the web page and saved it to PDF using the native print dialog in Firefox.
I have other Linux test machines but unfortunately they are of older versions and don't yet have a newer version installed.
See ya Monday!
1 of 1 people found this helpful
For a long time our instructions called for Linux users to create an account on their system with their university network ID which is also the account name in our PharosDB. However, using lpadmin, we have made it easier for our users to print through Pharos without needing to add this account. You can try something like the following shell script:
echo Do you plan on ever using a Copy Card 'Y' or 'N'
if [ $yes = 'Y' ];
echo Please enter your Network ID:
lpadmin -o printer-is-shared=false -p "Color-$puser-Printer" -D "Color-$puser-Printer" -v lpd://$puser@YourUniprintServer/YourQueueName -P /home/bin/uniprint/Dell_5130cdn.ppd -E
lpadmin -o printer-is-shared=false -p "Color-Guest-Printer" -D "Color-Guest-Printer" -v lpd://guest@YourUniprintServer/YourQueueName -P /home/bin/uniprint/Dell_5130cdn.ppd -E
echo Please enter your Network ID:
lpadmin -o printer-is-shared=false -p "Color-$puser1-Printer" -D "Color-$puser1-Printer" -v lpd://$puser1@YourUniprintServer/YourQueueName -P /home/bin/uniprint/Dell_5130cdn.ppd -E
Added purple text to areas you would want to change at minimum but hope you get the premise. We have another shell script to place the ppd file for the printer in the /home/bin/uniprint area and then runs this one.
Reason behind the bit at the top about copy cards is our card swipe script eliminates the need to have a keyboard at the release station. Our workaround was to have all users with a copy card use the name uniprint user named "guest" as we are not yet (if ever) populating pharos with those cards. This allows users to use either their guest copy card or their student ID (CBORD)
ps: Will be thinking of you all on Monday - have a great time! Hopefully the IL state budget will be fixed and we can attend the next conference =/
I like the script! A cautionary tale, though: this puts a network user name in a configuration file stored as clear text. This may or may not be considered a security flaw by some organizations.
Thanks for the catch, Scott! I should have mentioned that as well being security minded and having issues with a lot of ways network usernames are thrown around. This script is for personal devices only as we do not have very many Linux boxes used by staff or students that print through Pharos. My thought was that having it stored in this config file was "better" than forcing users to create another account on their machine with his/her network ID.