Printing from Pi

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.

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'.

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 ...

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?

Can you post a link to the tutorial?

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

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

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.

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.

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

...

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

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

Here's one:

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.

Thanks for this, Though I have made some progress this info should help me along.

Malcolm 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