Cups changes

Raspbian has the Debian "adduer" script whis is easier to drive than the LSB "usermod" tool, you could instead do "sudo adduser pi lpadmin"

Not really, but in there you could grant explicit admin permission to the user called "pi" instead of using the group "lpadmin"

that command is not compatibale with that file.

further reading:

man 8 usermod man 8 adduser man 5 cupsd.conf

This command adds the user "pi" to the group "lpadmin".

Just type it in the terminal once. The system will remember

Thanks for that info Jasen =. I will check your references. To Stefan, The system does not appear to remember, so when printing fails to work I have to type the command again I find. Printing then works again. This is of course after a shutdown.

Thanks Malcolm

As a check: run "sudo less /etc/group" and look for the your user name, 'pi', in the list. If you see a line something like "lpadmin:x:1000:pi" (the number is the user id and may differ) then your attempt to add the user 'pi' to the 'lpadmin' group was successful and its presence in /etc/group shows that this was permanently recorded.

The correct way to make sure that a command is run as root each time the system is booted is to add a line containing it to /etc/rc.local immediately before the 'exit 0' line. /etc/rc.local is run by root as one of the last actions when the system is booted so 'sudo' must not precede the command.

You might also check that the file defines a 'lpadmin' group and that this is the correct group for CUPS: I have cups installed on this laptop, which runs Fedora Linux, but its /etc/group file does not define an lpadmin group. I don't have cups installed on my RPi so I can't check on its printing setup.

That 'sudo' is superfluous, /etc/group has world read permission (as has /etc/passwd).

The whole sudo thing is superfluous, it only makes people think that in Linux you need to type sudo in front of any command.

It's generally safer than opening a root console or logging in as root. Obviously a sysadmin may find it just gets in the way, but that's a special case - for ordinary users sudo is convenient once you get used to it.

I prefer to limit sudo users to a few specific commands. For serious admin stuff I (sparingly) use su.

How is $ sudo rm -f $foo any safer than # rm -f $foo

I never quite understood why that should be the case.

I am an ordinary user, and I am the sysadmin of all my Linux boxes, as are most users I would guess. Always have been ever since I started using Linux some 15 years ago. I always keep one or more root consoles open. But then, I may just be the 'special case'. Can you give a valid reason to not be root other than the omnipresent 'don't do that'?

Paul

It isn't - but in a multi-user environment using sudo is safer than handing out the root password for a number of reasons.

1. You don't have to tall a bunch of people when you change it. 2. You can track who does what with admin permissions 3. You can control who can do what with sudo 4. You can revoke sudo permissions selectively 5. sudo usually insists on verifying that you know your password after a pretty short timeout which tends to stop other people using your sudo privileges.

There's a lot of Linux boxes in data centres around the world where most users are not admins.

Well I can think of a good reason not to leave root terminal windows lying around - if anyone else walks in they can do pretty much anything unless you are careful to lock your screen.

The only other benefit from having to type sudo to get root privileges is that it might prevent some accidents, so long as you don't reflexively type sudo in front of everything you do.

It is about as useful as asking "are you sure" when removing files. The first two or three times, it makes you think before you do. From then on, you have already hit y before you realize it was wrong.

The idea of sudo is that it would make you think before you run some dangerous superuser command. But, as this thread shows, in reality it just makes people type sudo in front of every command without thinking. It even infests "howto" guides found on internet, making them difficult to copy and paste into systems not using this nonsense.

When I am on a Pi or another box configured this way, the first thing I do when it is not my box is typing "sudo su" and when it is my own box, setting a root password and using "su". Of course I disable direct logins as root in sshd, but that is unrelated to this topic.

I use both methods:

Sudo with a limited command list is useful for one-offs, e.g. changing a file's ownership or permissions, running an install script for a script/ program I've just written.

Root login for anything more extensive such as running backups or tweaking & testing a daemon's configuration.

As this is the Raspberry Pi group, I think we are discussing the default setup in Raspbian which is like Ubuntu: the default user can run any root command with sudo and without a password.

That means anyone can run dangerous and disastrous commands just by prefixing them with sudo. I think that serves no purpose at all.

Yes. Routinely running stuff as root opens your entire system to malware attacks if you access an infected web page / download and run a malicious program or mistype and run something like "rm -rf * .txt" when you meant "rm -rf *.txt".

OTOH, if you do any of these things from a normal user with typically limited group memberships the possible damage is restricted to files owned by that user and in directories owned by him.

IMO only a fool would run a web browser or compile and test source you found on the net as root.

By restricting these activities to a login with default privileges and only moving stuff to /usr/local/bin when you're sure its safe and (reasonably) bug free you've vastly reduced your system's attack surface. Similarly, you should not reconfigure or disable its firewall or SELinux unless (a) you know what you're doing and (b) have a good reason for doing so. The same applies to opening ports through your ADSL modem/ router.

Windows users who give their default user Administrator privileges because they can't be arsed to login as Administrator from time to time, and then browse dodgy websites/download and run untrusted programs are effectively running this junk as root. This sort of stupid trick is the major reason why so many 'doze boxes are infested with malware, assorted crapware and/or spew spam over the 'net.

You need to type the "sudo", so you're aware that you're running something as root (assuming you have permission to run sudo and permission to run the specific application you're calling).

There are plenty of Linux machines out there that you wouldn't want ordinary users to have root access.

I don't recall sudo getting much use back then - it's probably still not installed by default in Slackware. When I started using more modern distros that encourage its use I found it a bit awkward at first, but soon got used to it.

Any time anyone else is using the box you /really/ don't want any root consoles open - I accidentally left a root console open on one of my boxes, another user found it, resulting in deleting my programming assignment that was due in the next day (he thought he was deleting his own temp files).

I certainly don't use it unless it's necessary - why would I want to run everything as root when I'm logged in as an ordinary user? I'd end up needing to run stuff as root, because of file permissions set when running sudo, that really shouldn't need it.

That's not entirely true. The need to prefix a command with sudo is a reminder to the user that they are using a command that has the potential to screw the OS over so therefore should be used with much greater care. From that point of view, it's about as effective as the UAC prompt (which is primarily a measure against malware instigated commands) in Vista and later windows versions.

I know what you mean. Users eventually become habituated into using the sudo prefix and become blase about the use of such commands, increasing the risk of a fatal command being issued. The hope, however, is that the user will have had sufficient practice by that stage in using these commands to be less likely of making such stupid mistakes.

The trouble, as you've observed, is that hope alone can't save a user from his/her own actions, especially as they become more cavalier in their use of the command line. You can't protect a user against their own actions and, since lessons learned are most effectively learnt by making mistakes, the user only really starts to learn about the system and its commands after they've made a mistake or three and can only blame their own stupidity for ignoring the warning implied by the need to use sudo as a command prefix.

Ah, but human nature being what it is, this is _exactly_ the habit that users will acquire. :-(