Setting up multiple users in Puppy
Puppy's design consideration
Most Linux distro are multi-users, but Puppy appears to be single users system that assumes you run as root. Is there some reason for this? Did Barry ever explain why it was written this way (for simplicity?)
Paul
Paul
- Dougal
- Posts: 2502
- Joined: Wed 19 Oct 2005, 13:06
- Location: Hell more grotesque than any medieval woodcut
How did Ubuntu get dragged into this thread??
As Nathan mentioned, this thread is not for discussing the merits of multi-user vs. single-user.
Neither is it for philosophizing about whether Puppy should have the option or not.
This is supposed to be a technical discussion about how to do it, be it for implementing into Puppy or so when we're old we can tell our grandchildren that we managed to get Puppy running multiuser.
If anyone wants to talk nonsense, they can go to any of the myriad threads in this forum consisting of that.
Now to busyness: I don't think it should be a problem to modify Puppy to accommodate the multiuser option without affecting the way it currently works.
Puppy can be as it is now, with some upgraded packages (such as mentioned by Nathan) and some slightly modified scripts.
It will run as it does now, but will have a "add user" option and the first time you add a user it will:
- get the root user to select a new password
- create the new user
- change your Puppy "installation" to run in multiuser mode
The last can be done by
1) (clumsy) installing a package
2) (better) modifying various scripts and files (/etc/inittab?) to how we need them in multiuser mode
3) (best) have everything built0in from the start, but just have some flag telling us to run multiuser
I really don't think that, for example, having in rc.local0 something like
will affect the "regular" use of Puppy…
As Nathan mentioned, this thread is not for discussing the merits of multi-user vs. single-user.
Neither is it for philosophizing about whether Puppy should have the option or not.
This is supposed to be a technical discussion about how to do it, be it for implementing into Puppy or so when we're old we can tell our grandchildren that we managed to get Puppy running multiuser.
If anyone wants to talk nonsense, they can go to any of the myriad threads in this forum consisting of that.
Now to busyness: I don't think it should be a problem to modify Puppy to accommodate the multiuser option without affecting the way it currently works.
Puppy can be as it is now, with some upgraded packages (such as mentioned by Nathan) and some slightly modified scripts.
It will run as it does now, but will have a "add user" option and the first time you add a user it will:
- get the root user to select a new password
- create the new user
- change your Puppy "installation" to run in multiuser mode
The last can be done by
1) (clumsy) installing a package
2) (better) modifying various scripts and files (/etc/inittab?) to how we need them in multiuser mode
3) (best) have everything built0in from the start, but just have some flag telling us to run multiuser
I really don't think that, for example, having in rc.local0 something like
Code: Select all
if [ -f /etc/.multiuser ] then
exec /etc/rc.d/rc.multiuser
fi
What's the ugliest part of your body?
Some say your nose
Some say your toes
But I think it's your mind
Some say your nose
Some say your toes
But I think it's your mind
- Nathan F
- Posts: 1764
- Joined: Wed 08 Jun 2005, 14:45
- Location: Wadsworth, OH (occasionally home)
- Contact:
GuestToo is right on both counts. Setting up a multi-user environment carelessly could very well result in a system that is less secure than what Puppy is by default. That's why it pays to tread carefully. Also, the permissions of /tmp should be as he says.
Dougal brings up a couple good points here too, although I don't think there needs to be an rc.multiuser file. Frankly, most distros can be run just fine as root in which case you will have a very Puppy-like experience. Basically once the environment is set up Puppy can behave normally as people are used to, but by changing the way inittab is set up there are a lot of possible options. Puppy could continue to log root in automatically at boot, or he could present a text mode login prompt, or he could start a login manager. It would not be too hard to create a small wizard which makes the switch easy.
And absolutely, the changes I have been making are unobtrusive to the way users expect Puppy to run.
Folks I'm honestly glad that the thread is attracting attention now, but please read the initial post and try to keep the comments relavent to a technical discussion, rather than a philosofical one.
Nathan
Dougal brings up a couple good points here too, although I don't think there needs to be an rc.multiuser file. Frankly, most distros can be run just fine as root in which case you will have a very Puppy-like experience. Basically once the environment is set up Puppy can behave normally as people are used to, but by changing the way inittab is set up there are a lot of possible options. Puppy could continue to log root in automatically at boot, or he could present a text mode login prompt, or he could start a login manager. It would not be too hard to create a small wizard which makes the switch easy.
And absolutely, the changes I have been making are unobtrusive to the way users expect Puppy to run.
Folks I'm honestly glad that the thread is attracting attention now, but please read the initial post and try to keep the comments relavent to a technical discussion, rather than a philosofical one.
Nathan
Bring on the locusts ...
everything that isn't technical is nonsense - dougal
sorry if there wasn't enough technical info for your taste, dougal, next time if you could please make your request to stay on topic a little more arrogant and pompous, and more insulting to half the people on the forum, that would be nice. i'm all in favor of people working on this, if i knew how i'd help. i did know about running as spot, which someone was interested in doing, and helped him with it.you could try running qemu (available as .pup) as spot, but it probably makes more sense to run apps like seamonkey and gaim or xchat as spot without emulation.
...ubuntu i had to reinstall because of the way it forces you to not be root. sudo is a fine OPTION
but since obviously i'm in the way here, i'll go sit on my thumb and let you GROWNUPS talk shop. christ.
nathan: sorry, couldn't help it. but i'll leave the thread anyway.
- Dougal
- Posts: 2502
- Joined: Wed 19 Oct 2005, 13:06
- Location: Hell more grotesque than any medieval woodcut
Hehe, that was just an example to show how little influence having the multiuser option will have on normal users...Nathan F wrote:although I don't think there needs to be an rc.multiuser file
My main point was that it should be done in a way changes the way Puppy works only if you've already added users -- so people can go on using Puppy without complaining about "having to log in" or anything.
What's the ugliest part of your body?
Some say your nose
Some say your toes
But I think it's your mind
Some say your nose
Some say your toes
But I think it's your mind
Defintely - the method is dependent on platform used, x-server & desktop Mgr !
There are varied CLI commands to change resolution
In Kde - no CLI needed , it's a snap - as a multi user exercise; EG logged on @ user -hot-keys;
Logon, startx option (symlink >initiate x) sources .xinitrc (user desktop still runing, 1st GUI = F7 =new concurrent GUI > (TTY F8)
*Left click (configurable window behaviour determines mouse *optional behaviour) on MT desktop > (menu) "refresh desktop"
Menu > change resolution - accept -reversible @ any time returns to users desktop
While in text console whichever unused TTY open - may be accessed
Gui desktops start TTY F7, Systems may be Cfg'd to use any above GUI for monitoring only
Ea. user may have far more concurrent/separate instances of GUI session desktops then ever used. (MEM limitations)
Ea. running session also may have numerous desktops (default 4 - configurable.)
KDEutils may run under varied W/Mgrs, I.E. Ice/Fluxbox
(requires some QT dependencies)
Kdrive (Tinyx) will not have comparable x-libs
There are few more complicated variances as X-servers.
http://www.rahul.net/kenton/xsites.html
BTW biases: ="sudo"(editable @ users risk) is @!!## BAD !
Far better >
There are varied CLI commands to change resolution
In Kde - no CLI needed , it's a snap - as a multi user exercise; EG logged on @ user -hot-keys;
Code: Select all
Ctrl+Alt+F2<to>F6
Logon, startx option (symlink >initiate x) sources .xinitrc (user desktop still runing, 1st GUI = F7
Code: Select all
Startx --:1 (2,3,etc)
*Left click (configurable window behaviour determines mouse *optional behaviour) on MT desktop > (menu) "refresh desktop"
Menu > change resolution - accept -reversible @ any time
Code: Select all
Ctrl+Alt+F7
While in text console whichever unused TTY open -
Code: Select all
Alt +F2<>F6
Gui desktops start TTY F7, Systems may be Cfg'd to use any above GUI for monitoring only
Ea. user may have far more concurrent/separate instances of GUI session desktops then ever used. (MEM limitations)
Ea. running session also may have numerous desktops (default 4 - configurable.)
KDEutils may run under varied W/Mgrs, I.E. Ice/Fluxbox
(requires some QT dependencies)
Kdrive (Tinyx) will not have comparable x-libs
There are few more complicated variances as X-servers.
http://www.rahul.net/kenton/xsites.html
BTW biases: ="sudo"(editable @ users risk) is @!!## BAD !
Far better >
Code: Select all
su -l
- Nathan F
- Posts: 1764
- Joined: Wed 08 Jun 2005, 14:45
- Location: Wadsworth, OH (occasionally home)
- Contact:
The Kdrive server (Xvesa) would be far easier to configure individually for each user because it does not read a global config file. Instead you pass it all arguments on the command line, including resolution. Not that it isn't possible with Xorg, it's just probably not as easy (and I've never investigated how because I haven't ever wanted to).
Nathan
Personal opinion I think. Sudo is no less secure than su, but if configured badly it can cause severe problems. Sudo allows the admin to specify which commands can be executed by whom with what permissions, and whether they need supply a password. Key points to remember when setting it up - don't allow users to run a program as root which they can escape to a shell from, ie you can easily open a terminal from most filemanagers. And specify the full path to each command, so users can't create an arbitrary program in their home directory with the same name, but malicious code. By contrast, giving the root password and allowing su means anything can be executed without any safety net.BTW biases: ="sudo"(editable @ users risk) is @!!## BAD !
Nathan
Bring on the locusts ...
Rationale is well understood - as is better alternatives:
Think group/wheel etal.
Then think Sys admin often owns wheels in danger of falling off
There is a REASON it is optional utility, not S.O.P.
For most "Sys Admins" sudo should have been spelt sloth.
They have yet to learn- playing w/own system does not translate:
Savoire sa lecon into insousciant "Don't put beans in your ears" !
Think group/wheel etal.
Then think Sys admin often owns wheels in danger of falling off
There is a REASON it is optional utility, not S.O.P.
For most "Sys Admins" sudo should have been spelt sloth.
They have yet to learn- playing w/own system does not translate:
Savoire sa lecon into insousciant "Don't put beans in your ears" !
As a non-technical power user who has interfaced with other operating systems apart from Microsoft's over a number of years, may I make a few comments, trying to stay within the guidelines Nathan outlined in his first post.
Running as root does not frighten me, indeed I find it extremely frustrating with some operating systems I've tried where they go out of their way to prevent you from using the system in the way that you - the owner of it - wish and choose to do.
My experience shows that providing you are careful with how you use your computer, and what you do with it, it is no more or less likely to get invaded, blown up, or destroyed by running as user or root.
I accept the thoughts that as root you can del /*.*
However, if you run puppy in the way it was designed - an unimaginably fast Live-CD system, that keeps all the files it loads from read only by virtue of the media sitting in a read only CD drive, you can't destroy the OS by using puppy.
If you let a nastie in, so what, in actual fact. It isn't going to change anything except what is in RAM or swap file.
If you maintain your own personal file (read-write on an HDD) with regular backups, then if that does get destroyed, even then, so what?
I always back up my work as I go, and at the end of a session most times. Something when I taught AutoCAD users back in Version 2 days I continually emphasised.
With puppy you can restore a clean system and data in simple steps
1. reboot in pfix=ram mode,
2. copy back your pup_save.2fs (or 3fs) file and
3. then reboot again using the restored pup_save file.
It isn't hard, difficult, or really time-consuming.
Multiple users is another thing altogether. I wouldn't want others to browse through my documents, perhaps changing things, or deleting them.
Actually I developed a series of red-coloured root user wallpapers to suit a range of computer OS's (I won't call them distributions because that upsets Unix users - BSD anyway lol). I have published these explaining how SuSE gives its system owners the opportunity to use default wallpaper that continually reminds them of being "root". You should read some of the comments from some on the forums I've shared this information with!!
It isn't hard to make root logins work in KDE even if they've been prevented. Ubuntu is Gnome, and that's a dog of a different colour. I don't like Ubuntu anyway (not for that reason, lol)
I don't like having to keep entering the root password if I'm doing a task that needs root and I am only allowed to do it sudo. It is counter-productive.
You might be interested in looking at my "root wallpaper" page here but don't come back and flame this thread as you will incur Nathan's wrath as he laid down the ground rules in the first post. Like I did in the PC-BSD forums, but that didn't stop the slashdot types lolol
You might even like to look at the (currently four) pages of responses to that thread here.
Richard
Downunder
Running as root does not frighten me, indeed I find it extremely frustrating with some operating systems I've tried where they go out of their way to prevent you from using the system in the way that you - the owner of it - wish and choose to do.
My experience shows that providing you are careful with how you use your computer, and what you do with it, it is no more or less likely to get invaded, blown up, or destroyed by running as user or root.
I accept the thoughts that as root you can del /*.*
However, if you run puppy in the way it was designed - an unimaginably fast Live-CD system, that keeps all the files it loads from read only by virtue of the media sitting in a read only CD drive, you can't destroy the OS by using puppy.
If you let a nastie in, so what, in actual fact. It isn't going to change anything except what is in RAM or swap file.
If you maintain your own personal file (read-write on an HDD) with regular backups, then if that does get destroyed, even then, so what?
I always back up my work as I go, and at the end of a session most times. Something when I taught AutoCAD users back in Version 2 days I continually emphasised.
With puppy you can restore a clean system and data in simple steps
1. reboot in pfix=ram mode,
2. copy back your pup_save.2fs (or 3fs) file and
3. then reboot again using the restored pup_save file.
It isn't hard, difficult, or really time-consuming.
Multiple users is another thing altogether. I wouldn't want others to browse through my documents, perhaps changing things, or deleting them.
Actually I developed a series of red-coloured root user wallpapers to suit a range of computer OS's (I won't call them distributions because that upsets Unix users - BSD anyway lol). I have published these explaining how SuSE gives its system owners the opportunity to use default wallpaper that continually reminds them of being "root". You should read some of the comments from some on the forums I've shared this information with!!
It isn't hard to make root logins work in KDE even if they've been prevented. Ubuntu is Gnome, and that's a dog of a different colour. I don't like Ubuntu anyway (not for that reason, lol)
I don't like having to keep entering the root password if I'm doing a task that needs root and I am only allowed to do it sudo. It is counter-productive.
You might be interested in looking at my "root wallpaper" page here but don't come back and flame this thread as you will incur Nathan's wrath as he laid down the ground rules in the first post. Like I did in the PC-BSD forums, but that didn't stop the slashdot types lolol
You might even like to look at the (currently four) pages of responses to that thread here.
Richard
Downunder
[i]Have you noticed editing is always needed for the inevitable typos that weren't there when you hit the "post" button?[/i]
[img]http://micro-hard.dreamhosters.com/416434.png[/img]
[img]http://micro-hard.dreamhosters.com/416434.png[/img]
- Nathan F
- Posts: 1764
- Joined: Wed 08 Jun 2005, 14:45
- Location: Wadsworth, OH (occasionally home)
- Contact:
That's not a bad idea, and you gave me a good reminder. I used to have my system set up something like this, and also had things arranged so root used different gtk themes and such. That way even running just one program as root you can tell it visually. I also have my root shell prompt set up a bit differently (besides the standard $ for users, # for root). On the one machine root's shell prompt is always red, while everyone else gets plain green.
Anyway this is good advice for most situations. I need to institute this in my own projects as well.
Nathan
Anyway this is good advice for most situations. I need to institute this in my own projects as well.
Nathan
Bring on the locusts ...
Another reason Puppy REALLY NEEDS multiuser rebuild.......
Lots of software require multi user......
If you don't they say:
Now a real life software example.....
Ever heard of the very popular Xscreensaver?
After installing OpenGL(by Mesa3D) I compiled this.
Then installed it.
And typing xscreensaver in the prompt, an error....
Now I wasn't a that much of a newbie, so I went to CHMOD the "xscreensaver-gl-helper"
to 777. It was successful in CHMODing, but running it again.....
And even creating another user doesn't work!
Running is says access denied, and some errors...
And Puppy hates multi users!
So can anyone please recompile Linux for multiuser????
A couple notes....
I am developing a dotPup for OpenGL's Mesa3d along with prerequisites and the Xscreensaver itself.
The first shots of the terminal are when XScreensaver is already running. The last ones are no running processes of XScreensaver.
Lots of software require multi user......
If you don't they say:
(something like that....)Can't run as root
Now a real life software example.....
Ever heard of the very popular Xscreensaver?
After installing OpenGL(by Mesa3D) I compiled this.
Then installed it.
And typing xscreensaver in the prompt, an error....
sh-3.00# xscreensaver
xscreensaver: couldn't get user info of uid 65534
xscreensaver: 18:18:05: running xscreensaver-gl-helper: Permission denied
xscreensaver: 18:18:05: already running on display :0.0 (window 0x2800037)
from process 32070 (???@puppypc).
sh-3.00#
Now I wasn't a that much of a newbie, so I went to CHMOD the "xscreensaver-gl-helper"
to 777. It was successful in CHMODing, but running it again.....
And to find a little more details.....(killing the already running process.....)sh-3.00# chmod 777 /usr/local/bin/xscreensaver-gl-helper
sh-3.00# xscreensaver
xscreensaver: couldn't get user info of uid 65534
xscreensaver: 18:20:38: running xscreensaver-gl-helper: Permission denied
xscreensaver: 18:20:38: already running on display :0.0 (window 0x2800037)
from process 32070 (???@puppypc).
sh-3.00#
Now for a surprise.... This wasn't that much of a detail, right? Look at this.....xscreensaver: couldn't get user info of uid 65534
xscreensaver: 18:21:42: running xscreensaver-gl-helper: Permission denied
xscreensaver: 18:21:42: locking is disabled (running as <unknown>).
xscreensaver: 18:21:42: locking only works when xscreensaver is launched
by a normal, non-privileged user (e.g., not "root".)
See the manual for details.
So you can see, xscreensaver DOES NOT want you to be root.sh-3.00# xscreensaver-demo
xscreensaver-demo: 18:24:18: we're still running as root! Disaster!
xscreensaver: couldn't get user info of uid 65534
xscreensaver: 18:24:23: running xscreensaver-gl-helper: Permission denied
xscreensaver: 18:24:23: locking is disabled (running as <unknown>).
xscreensaver: 18:24:23: locking only works when xscreensaver is launched
by a normal, non-privileged user (e.g., not "root".)
See the manual for details.
xscreensaver-demo: 18:24:28: we're still running as root! Disaster!
xscreensaver-demo: 18:24:31: we're still running as root! Disaster!
sh-3.00#
And even creating another user doesn't work!
Running is says access denied, and some errors...
And Puppy hates multi users!
sh-3.00# login demo
Password:
-sh: error while loading shared libraries: libreadline.so.5: cannot open shared object file: Permission denied
sh-3.00#
So can anyone please recompile Linux for multiuser????
A couple notes....
I am developing a dotPup for OpenGL's Mesa3d along with prerequisites and the Xscreensaver itself.
The first shots of the terminal are when XScreensaver is already running. The last ones are no running processes of XScreensaver.
I was just wondering the last couple of days, could you do a frugal/multisession multiuser just by swapping pup_save files? My undestanding is these files contain all your settings and docs (if you save into it).
So if it found pup_save_david.2fs and pup_save_johnny.2fs both in mnt/home it would just pop up a dialog and let you select the one you want, the same as it does now when it finds .sfs files there. Maybe a SaveNow for frugals could have an option of making a new pup_save.
I guess it would have to be earlier in the boot process so things like XOrg setting would stick etc.
I can't really follow it, but maybe this is what people are already suggesting above? Seems easy from my amateur perspective.
David
So if it found pup_save_david.2fs and pup_save_johnny.2fs both in mnt/home it would just pop up a dialog and let you select the one you want, the same as it does now when it finds .sfs files there. Maybe a SaveNow for frugals could have an option of making a new pup_save.
I guess it would have to be earlier in the boot process so things like XOrg setting would stick etc.
I can't really follow it, but maybe this is what people are already suggesting above? Seems easy from my amateur perspective.
David
David,
Two things...
1 -- I've found that in many cases, regardless of what computer hardware has been seen when a pup_save.(x)fs file is created - ie even if it wasn't the machine you are currently seated at (with different hardware etc) that you can use that file in the new location with probably little more than having to run xorgwizard over again.
2 -- I have even copied the same pup_save.(x)fs file under several different names to the same drive filesystem root directory, for subsequent editing into specific different configurations.
You probably need to remember to keep evident in the filename the version of puppy, because otherwise you run the risk of destroying the configuration by accidentally upgrading to a more recent version. Like this...
If they are FAT partitions where you save them, though, they often become badly fragmented, which the NT defragmenter isn't always clever at handling. One reason I keep win98SE around is for defragmenting big files like these, and also VMware Virtual Machine files which also seem to get laid down badly.
If you have your pup_save files on an USB IDE HD, then you can transport them to a w98 computer to defrag them
Regarding sfs files, I haven't yet discovered what you need to do to select them, because I've never seen a menu. Perhaps you can enlighten me here?
Richard
Two things...
1 -- I've found that in many cases, regardless of what computer hardware has been seen when a pup_save.(x)fs file is created - ie even if it wasn't the machine you are currently seated at (with different hardware etc) that you can use that file in the new location with probably little more than having to run xorgwizard over again.
2 -- I have even copied the same pup_save.(x)fs file under several different names to the same drive filesystem root directory, for subsequent editing into specific different configurations.
You probably need to remember to keep evident in the filename the version of puppy, because otherwise you run the risk of destroying the configuration by accidentally upgrading to a more recent version. Like this...
I regularly save to different drives (including USB IDEs) and different partitions without much of a problem.pup_save_202basic.3fs
pup_save_215ce.3fs
pup_save_216ex.2fs
If they are FAT partitions where you save them, though, they often become badly fragmented, which the NT defragmenter isn't always clever at handling. One reason I keep win98SE around is for defragmenting big files like these, and also VMware Virtual Machine files which also seem to get laid down badly.
If you have your pup_save files on an USB IDE HD, then you can transport them to a w98 computer to defrag them
Regarding sfs files, I haven't yet discovered what you need to do to select them, because I've never seen a menu. Perhaps you can enlighten me here?
Richard
[i]Have you noticed editing is always needed for the inevitable typos that weren't there when you hit the "post" button?[/i]
[img]http://micro-hard.dreamhosters.com/416434.png[/img]
[img]http://micro-hard.dreamhosters.com/416434.png[/img]
When I restart X in 2.16 I get the attached dialog, maybe you need some sfs in /mnt/home before it shows? Anyway it occured to me something very similar could let you select the 'user' by presenting a list of 'pup_saves'.richard.a wrote: Regarding sfs files, I haven't yet discovered what you need to do to select them, because I've never seen a menu. Perhaps you can enlighten me here?
I started thinking about this, because recently I've been using a frugal install on HDD, saving documents to /mnt/home (ie direct to HDD instead of via pup_save). This way pup_save just has my applications and settings, and I use it to set up new installs without remastering (which I haven't tried yet).
Point taken on keeping different versions marked.
DB
- Attachments
-
- sfsbootmanager.png
- (28.06 KiB) Downloaded 2877 times
-
- Posts: 31
- Joined: Wed 28 Nov 2007, 00:47
- Contact:
*Sigh* Boy, people have such misconceptions about hackers. Ok, basically, hacking is not breaking into others computers. That's cracking (CRiminal hACKING). Or, if you prefer, black hat hacking. MOST hackers aren't like what you here about on tv. *If you google search ethical hacking, you'll see what I mean.* Hackers test security with consent. There are even government issued hacking licenses. Besides that, 9 out of 10 cracker only know enough to cause a little trouble. In order to hack a linux box, you need a lot of skill. I agree completely with making a multiuser puppy. But really, it IS like.. impossible to hack a linux computer. The only way it's possible is by users making extreme changes to security or using things like IM clients that are old and insecure. *Even then, you normally can't cause much damage*
Still it would be nice to know that, if a cracker got into the computer, it would be hell for them to cause damage.[/b]
Still it would be nice to know that, if a cracker got into the computer, it would be hell for them to cause damage.[/b]