booting direct into Xwindows without login

win32sux · 03-27-2005, 10:18 PM

okay, i'm gonna try it that way right now...

but i actually have several commands in my rc.local and none of them needed the absolute path specified...

DaWallace · 03-27-2005, 10:20 PM

most of the time anything X related goes in a different path.

win32sux · 03-27-2005, 10:29 PM

okay, i tried with:

Code:

su win32sux -c /usr/X11R6/bin/startx

and still no luck... here's what i get now:

Quote:

/usr/X11R6/bin/startx: line 132: xauth: command not found
/usr/X11R6/bin/startx: line 133: xauth: command not found
/usr/X11R6/bin/startx: line 132: xauth: command not found
/usr/X11R6/bin/startx: line 133: xauth: command not found
/usr/X11R6/bin/startx: line 141: xauth: command not found

DaWallace · 03-27-2005, 10:32 PM

damn. you'll have to add /usr/X11R6/bin to the PATH variable before trying to do startx.

and this would probably work better from inittab.. but the method would be somewhat different.

win32sux · 03-27-2005, 10:37 PM

what about doing this in /etc/rc.d/rc.M, right after rc.local is called??

or maybe in /etc/rc.d/rc.4 ??

DaWallace · 03-27-2005, 10:39 PM

that would be preferrable.. but I'd wait until it works.

win32sux · 03-27-2005, 10:42 PM

okay i'm looking at rc.M and rc.4 to see what i can try...

i might make an /etc/rc.d/rc.autologin (with the su startx in it) and call it from somewhere in rc.4 or something...

win32sux · 03-27-2005, 11:00 PM

okay i made an /etc/rc.d/rc.autologin which contained this:

Code:

#!/bin/sh
su - win32sux -c startx

i made it executable (chmod 755 /etc/rc.d/rc.autologin) and added these lines to /etc/rc.d/rc.4:

Code:

if [ -x /etc/rc.d/rc.autologin ]; then
  exec /etc/rc.d/rc.autologin
fi

i edited my /etc/inittab so i would start in runlevel 4...

i rebooted and i was greeted by the dreaded "startx command not found" error...

so i'm back to square one...

=(

win32sux · 03-27-2005, 11:23 PM

okay, i googled this paper: http://linuxgazette.net/issue72/chung.html

it's almost 4 years old, but i've got nothing to lose so i might try it... i'd love to get your opinion, though... what do you think??

BTW, thanks for all your help DaWallace, i really appreciate it!!!

Quote:

Using your favourite text editor create a file named autologinfred.c and type in this short C program:

Code:

int main() {
   execlp( "login", "login", "-f", "fred", 0);
}

The execlp system call invokes the command "login -f fred" and replaces the current processing context with this invocation. The man page for login describes the action of the -f argument. Compile this tiny C program using the GNU C-compiler:

Code:

$ gcc -o autologinfred autologinfred.c

Gain root privileges (using su) and copy the executable to a public directory:

Code:

# cp autologinfred /usr/local/sbin/

Now take a look at /etc/inittab. This is the configuration file is used by init, the very first process started when Linux initialises. You should observe lines similar to the following:

1:2345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
3:2345:respawn:/sbin/mingetty tty3

The exact contents of /etc/inittab differ from distribution to distribution. On Debian systems one sees:

1:2345:respawn:/sbin/getty 38400 tty1
2:23:respawn:/sbin/getty 38400 tty2
3:23:respawn:/sbin/getty 38400 tty3

Edit the line beginning with "1:2345" so that it reads as follows:

1:2345:respawn:/sbin/getty -n -l /usr/local/sbin/autologinfred 38400 tty1

The above will cause the user fred to be logged in automatically on the first virtual console. On some GNU/Linux distributions (like RedHat) /sbin/agetty must be used instead. The -l <alternative login> argument to getty substitutes the default /sbin/login program with the one we compiled earlier. The -n tells getty to not prompt for a user ID.

Initiating the desktop on login

If we reboot, the init process will automatically login the user fred on the first virtual console and a command shell will by started. User fred must still type in the startx command to initiate the graphical desktop. Can we automate this too?

If fred's login shell is /bin/bash, the first commands to be executed will always be listed in the file, ~fred/.bash_profile. We can add the startx command here but this causes problems, since the .bash_profile will be used in other situations such as when one is logging into a second virtual console or when opening an xterm. Instead we append the following lines:

if [ -z "$DISPLAY" ] && [ $(tty) == /dev/tty1 ]; then
startx
fi

Any new login shell started on the first virtual console will automatically initiate a graphical desktop. The surrounding if statement ensures that login shells launched from the desktop, or initiated in virtual consoles other than the first one, do not immediately start up a new GUI desktop. Users of /bin/sh should append the above to ~fred/.profile, and tcsh users need to convert the above to the equivalent csh script.

If there is already a GUI desktop running (via xdm, gdm or kdm, etc) then invoke startx -- :1 instead. This creates a second GUI desktop. If one need only have one desktop active, it would be better to disable any existing Xserver instance by reducing the run level (RedHat) or unlinking the /etc/rc?.d/S99?dm start up configuration files (Debian).
Variations

Now whenever the machine boots, user fred is automatically logged into the first virtual console, a bash login shell is initiated, his ~/.bash_profile is sourced, and startx is invoked -- all without any user interaction or prompting for passwords. Neat, huh?

We can go further by making use of the ~/.xinitrc file to initiate particular desktop applications. (man startx for details.) Place your favourite game here and a Linux box can be used like one of those arcade machines, minus the decorative case. Launch an Ogg Vorbis player with visualisations and you can have a dedicated music machine.

Unprompted logins can also be useful in a non-graphical context. One could arrange to login a special user who has /usr/bin/top as her shell. Now one virtual console will be devoted to an interactive listing of active processes. The possibilities are limitless.
Conclusion
GNU/Linux, the multi-user operating system, is steadily becoming more popular in single user settings. In these situations one often can dispense with the user login protocols. This article illustrates that its roots in the UNIX world do not detract from using Linux in these dedicated areas. With simple changes in configuration, and a small touch of programming, one can automate the login process on most GNU/Linux distributions and still preserve a significant measure of flexibility.

win32sux · 03-28-2005, 01:15 AM

well, i tried the thing in the paper above... i compiled the code:

Code:

int main() {
   execlp( "login", "login", "-f", "win32sux", 0);
}

into a binary called /usr/local/sbin/autologinwin32sux and edited my /etc/inittab as described above:

Code:

c1:1235:respawn:/sbin/agetty -n -l /usr/local/sbin/autologinwin32sux 38400 tty1 linux

but the result i got was that upon startup i'd get prompted for the password *only*... i'd give it the win32sux password and then i could work normally... if i'd do an "exit" i'd get thrown back into the password prompt... only a password prompt, no login prompt... and just on tty1, of course... so i know the binary is having some effect, but it's not having the complete/desired effect... maybe there's something that needs to be tweaked in the code to make it work with slackware... i don't know, i give-up for today... =)

alexklant · 04-04-2005, 05:08 PM

Hi

The nuts-n-bolds method above from Linux Gazette,
didn't work for me either cause login -f user is still asking for a password.

The su-method didn't work, same as for win32sux.
PATH is set to /usr/X11R6/bin in /etc/profile.
But when i do su user, PATH has only
/usr/local/bin:/bin:/usr/bin.

But as stated earlier, there is the [-] option, which gives us
a nice PATH. But still, doesn't work if
run with su - user -c /usr/X11R6/bin/startx.

Isn't there a better way?

Regards, Alex

Shade · 04-05-2005, 05:46 PM

a quick fix -- insert this code into the end of rc.local or rc.M

Code:

source /etc/profile
export $PATH
startx &

That should set up all the correct paths as well as start a root X session. (cringe)
--Shade

win32sux · 04-09-2005, 02:08 AM

thanks to the post above, i've been able to successfully achieve an auto-login (into X11 from runlevel 3) with a regular user account by simply appending a line like this to /etc/rc.d/rc.local:

Code:

su win32sux -c "source /etc/profile && startx"

however, i still need to play around with this a little more, cuz there might be some problems that i haven't noticed yet...

i didn't use the "export $PATH" command as it was throwing an error and things seem to have worked well without it...

please let me know if this works for you guys and also please share any suggestions or observations you may have...

gbonvehi · 04-09-2005, 02:45 AM

I used this formula sometime ago to log into X sucessfuly from rc.local (it's very similar to yours):

Code:

su - gbonvehi -c 'source /etc/profile; source /home/gbonvehi/.bash_profile; startx&'

Without using the && the command don't have tu be successfull, but it's actually the same because if you can't import /etc/profile you won't get the PATH vars to execute X11.

kencaz · 04-09-2005, 02:55 AM

Quote:

Originally posted by DaWallace
I can't imagine why you'd want to do anything as stupid as that. but, you can add startx to the last line of your /etc/rc.d/rc.local and that will do it.

note: don't ever do that.

Amen! There is a thread floating around here in Linux-Security "Is linux secure because lack of users" That's a good one. If you think about it. Linux has always been geared towards security, where-as, windows just did not pay much attention and now there having major security problems and are trying to fix what should have been implemented in the begining.

I am sure there are applications where you would want to auto-login to your computer and if it's in your home even more so... Still, Linux is designed to be secure and that user's can't make changes that would screw up the system, (windows only recently added this type of administration recently, and from Linux/Unix I might add),

I think Linux has servived the onslot of hacks, cracks, and holes, not because of lack of users but because Linux user's recognize the need for security.

<end of line>

KC