Post a Comment
"cool"? Not really. But it can be handy - I used singleuser a few months ago to clone over my install to a new drive.
But the article linked-to wasn't about trying to say anything was "cool". It was just a basic listing of modes. It failed to explain what these modes could be used for, so wasn't very good at all.
Also, different systems can use different values - Slack comes to mind.
More like dis-information without some mention of System V, almost seems like redhat invented it. No mention of init/shutdown/reboot etc. or how you would even use that knowledge.
Runlevels control services started by the initialization process
is not a sentence or was it meant as a section title?
when debugging a driver level crash, single user mode in windows is very very handy. Just because most people don't know something exists doesn't make it less important to those that do.
Also, any home/consumer user of linux should care about run levels as they are a necessary piece of knowledge.
I am a home user of OS X, Linux and Windows, and I sure as hell care. Don't overgeneralize.
Did you checked this ? Do you know this ?
You can do this with Linux also.
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/fs-acl.ht...
The BSD approach is much simpler: you have single-user mode and multi-user mode.
Single-user mode is just the kernel + a shell, from which you can do administrative tasks (fsck, backup/restore, ...), and start additional services (networking, ...) individually using the rc.d system.
Multi-user mode is started when quitting the single-user mode shell, or just booting up normally. In multi-user mode, all services enabled in /etc/rc.conf are started. If you want to restart XDM for example, you don't need to switch runlevels, you just do a /etc/rc.d/xdm restart. If you want to disable networking, you do /etc/rc.d/network stop.
Halting and rebooting is done with the shutdown(8) command: "shutdown -h now" (or -p for halt+poweroff) and "shutdown -r now", which properly stop all running services.
If you want to restart XDM for example, you don't need to switch runlevels, you just do a /etc/rc.d/xdm restart. If you want to disable networking, you do /etc/rc.d/network stop
Like with most init implementations ...
Anyway, this article is so dumbed down it's wrong at times, even though the author seems to know what he's talking about.
He should have stated he was talking about a SysV or BSD type of init. Because runlevels are not specific to Linux at all, they depend on the "init" process used.
Some init do not even use true runlevels.
It's not true either that su is always called in single user mode. In some setups (like LDAP based, PAM based with some network access), doing this will make your OS unbootable. Sulogin is often used, as you're sure to get the prompt. I think the author made a mistake, as I don't think su will give you the promp without password (unless PAMed to do this), and I don't think su can be used as a login program either. So I think he meant sulogin.
His security problem is bogus too. If you can change the boot sequence at the lilo level, you can as well launch a shell instead of init, and thus get root access as easily.
Everything else he says is dependant on init too (where files are put, format of inittab, ...).
Well, first hit on google was excellent:
http://lists.debian.org/debian-devel/2003/01/msg01898.html
The 'correct' way is to use update-rc.d to stop gdm running in (for example) runlevel 3.
It's easier to install sysv-rc-conf (Debian package name) and use that to manage the symlinks instead. Running sysv-rc-conf as root gives you a nice grid of checkboxes showing which services will be started / stopped in each runlevel -- just uncheck gdm in runlevel 3.
sysv-rc-conf can also be used in the style of chkconfig on Red Hat, so something like this is also possible:
# sysv-rc-conf --level 3 gdm off
Section 2.4 of the Debian Reference[1] contains a good overview. Section 9.3 of the Debian Policy Manual[2] is good reading if you are really interested in what goes on under /etc/init.d
[1] http://www.debian.org/doc/manuals/reference/ch-system.en.html#s-boo...
[2] http://www.debian.org/doc/debian-policy/ch-opersys#s-sysvinit
and with single user u can reset the root password, there is some tricks and stuff you can do to midigate this but still.
id like to see this go away.
Also, if you have root access, you can change the password, too, and do lots of other bad things...
What's your point? The only ways to get into single-user mode are to be root, or to have physical access to the computer. In either case, you have enough power already - so single-user mode is not exactly a security hole.
"and with single user u can reset the root password, there is some tricks and stuff you can do to midigate this but still."
There's no need to mitigate this, it's the intended behaviour.
If you havent secured the physical access to the machine you have bigger problems than that the root password can be changed.




