Printing from Pi

Using Raspian on my Pi I am following a tutorial " setting up a
printer on your Pi"
I have downloaded CUPS and modified the config file 'cupsd.conf' as
instructed. But the change "allow localhost, Allow 172.20.22.* under
" # Restrict access to server" does not survive the save routing. with
the message 'Permission Denied'.
I have also tried to add a printer after accessing
http://localhost:631/ and again a message 'access forbidden'
What am I missing?
Malcolm Smith
--
T M Smith 
Using an Iyonix and RISC OS 5.20 in the North Riding of Yorkshire
Reply to
T M Smith
Loading thread data ...
Not using sudo. In general files in /etc and its subdirectories can only be edited in two ways: (1) by logging in as root, (2) via a command line and prefixing the editing command with sudo.
The sudo command temporarily escalates you to root privilege while the command following it runs. See "man sudo" for more information.
Look at the result of running "ls -l /etc/cupsd/cupsd.conf" to see why. Hint look at the permission flags and the file ownership.
--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
 Click to see the full signature
Reply to
Martin Gregorie
If you're going to do a lot of work as root (e.g. editing some files a and restarting server processes, etc.) then it's less tiresome to do:-
sudo -i
Then you become root as if you had logged in as root and have root privileges until you 'exit'. It avoids having to prefix everything with 'sudo'.
--
Chris Green
Reply to
cl
I find it's not hard to type an extra five characters, and it provides a valuable safeguard against accidentally doing something with root privileges. Admittedly I can be very absent minded, more focused users may feel they trust themselves with a root shell ...
Reply to
Rob Morley
It does flag itself quite well with a different prompt.
If you're 'absent minded' you can do quite a lot of damage without being root! :-)
In fact apart from the obvious 'rm -fr' what is one likely to do that root privelege will somehow make it a big disaster?
--
Chris Green
Reply to
cl
Can you post a link to the tutorial?
Reply to
mm0fmf
It is part of the book "Raspberry Pi for beginners"; setting up a printer on your Pi. Unfortunately not a tutorial on the internet.
Malcolm
--
T M Smith 
Using an Iyonix and RISC OS 5.20 in the North Riding of Yorkshire
Reply to
T M Smith
I did check permissions on the file and that seemed OK ; or 'thinks' did I set it to OK and it was not accepted!!.
The tutorial shows two sudo commands :- sudo nano /etc/cups/cups.d.conf sudo usermod -a -G lpadmin pi
These I typed in at the command line since it said they were to make the printer accessible over the internet. Though they were in the section concerned with modifying the conf file and I was somewhat confused as to how htey were to be treated.
Malcolm
--
T M Smith 
Using an Iyonix and RISC OS 5.20 in the North Riding of Yorkshire
Reply to
T M Smith
This is using the nano editor to change the cups server's configuration. I can't say more since you don't say what was to be changed. I assume you did that OK.
This adds the user 'pi' to the lpadmin group, i.e. gives user pi printer administrator privilege. Questions: - did it work? - is 'pi' your usual login on the RPi? If not, try it again but replace 'pi' with your login name.
Hint: when you're asked to use a command you haven't seen before or where you've forgotten what it does, get into the habit of running the "man commandname" command first so you'll know what it it meant to do.
I don't manage my printers that way (I don't print from my RPi). My printers are connected to boxes running Fedora Linux on Intel and use what are probably quite different applets provided by the XFCE desktop.
--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
 Click to see the full signature
Reply to
Martin Gregorie
Might not even be oneself - I lent my PC to a colleague at uni and he somehow managed to delete my programming assignment (which I didn't have time to rewrite) all because I'd left a root xterm open.
Reply to
Rob Morley
What else could one do as root besides remove files? Let me count the ways...
By happenstance, yesterday, I ran a bash script I was debugging on the main group development server at work. I had a spelling error in the name of a shell variable. One command copied many files from an OS installer ISO to another tree. Because bash replaces unset shell variables with empty string, the spelling error caused the script to dump a bunch of files in '/', including overwriting /boot/grub/grub.conf. Ouch!!!
On a Raspberry Pi, as long as you can make backups of the SD card, you're covered--just restore the SD card from a backup and you're back in business.
HTH
--
Robert Riches 
spamtrap42@jacob21819.net 
 Click to see the full signature
Reply to
Robert Riches
...
One danger I very nearly fell foul of was adding an ostensibly innocuous test to an existing loop - something like the following
if [$a > $b]
I cannot remember the exact code but it was in a shell script and not being anything like familiar enough with shell scripting it didn't quickly enough occur to me that the > sign does not mean "greater than" but "(over)write the following file". Unfortunately the "$b"s in the loop were thousands of existing file names.... (I think the test should have been -gt or something similar instead of >.)
I'm not sure why the code did not damage any files but it did not. However, it made me realise that shell scripts are not suitable for the non-experts. Even if they look harmless to a programmer they may not be. Either learn them well and use them or stay away from them.
After that close call I tend to avoid shell scripts and use Python if I need to script something.
James
Reply to
James Harris
Changes being made were to edit the CUPS config file under #Default authentification type :-
Browsing On BrowseOrder allow,deny BrowseAllow @LOCAL
followed by the two sudo commands. Following the two sudo commands came under # Restrict access to the server:-
Order Allow,deny Allow localhost Allow 172.20.22.*
Then 'restart the server with' #/etc/init.d/cupsys restart
Perhaps not since my changes were rejected.
yes pi is my login name
That sounds very useful, I will try it.
yes, understood Thanks for your input.
Malcolm
--
T M Smith 
Using an Iyonix and RISC OS 5.20 in the North Riding of Yorkshire
Reply to
T M Smith
On Fri, 13 Jun 2014 23:25:52 +0100, T M Smith , > >
Here's one:
formatting link

I alternate between adding printers via the web interface and on the command line such as:
lpadmin -p queue-name -E -v socket://IP:9100 -m relevantprinter.ppd
that's for a networked printer, using the HP JetDirect protocol. When you go to add a printer via the web interface, it should ask you for an authorized username/password. I generally use root after opening http://localhost:631/ as that's reasonably safe, but any account with sufficient privileges should work.
Also: when you add a logged in account to a new group, the changes aren't seen until that account has logged out and back in again.
--
Consulting Minister for Consultants, DNRC 
I can please only one person per day. Today is not your day. Tomorrow 
 Click to see the full signature
Reply to
I R A Darth Aggie
Thanks for this, Though I have made some progress this info should help me along.
Malcolm Smith
--
T M Smith 
Using an Iyonix and RISC OS 5.20 in the North Riding of Yorkshire
Reply to
T M Smith
Hi all,
Personally I've had bad experience using my raspberry pi as a print server. ghostscript takes a long time to render e.g. PDFs containing images into postscript. My conclusion is that the raspberry pi is too slow and has too little RAM to be suitable as a print server. Furthermore, the temp files get rather large and this puts wear on the SD card.
I have a Samsung printer which recieves its data via the proprietary QPDL language. I've mitigated the issues with ghostscript by making a separate lpd queue which directly takes QPDL input (so that the anything -> Postscript -> QPDL conversion process takes place on one of the x86 machines, which is a lot better).
Just thought this was relevant information at this point.
Best regards,
Moritz
Reply to
mw

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.