yep. Depending on the bios you may have to have a keyboard hooked up to it for it to boot up.
When linux boots up it uses concept called runlevels. Usually runlevel 5 is the X windows runlevel. That is when it finishes booting up it goes to runlevel 5 and provides you a graphical login. Runlevel 3 is the normal multi user runlevel, meaning you get the command line at the end of it. Runlevel 1 comes up when your booting up and runlevels 0 and 6 are for either rebooting or shutdown. But you have to keep in mind that their is no hard and fast rule to this runlevel thing. It can vary from distro to distro.
Another thing. Each program is the child of another program. Like this:
you start of at a login prompt. you enter you user name and password and get a bash shell. From that bash shell you startx, from startx you start X from X you start kdeinit, from kdeinit it loads all the kde gui stuff from that and you open a xterm. From that xterm you open ssh and login to a remote computer. If you use a command: "ps -AH" from the command prompt you can see all these relationships. So if you issue a kill to that first startx it will shutdown all the X stuff, kde stuff and all the programs you started in it including the ssh session.
However were does it all start? If a program needs something to start it, what is the very first program to start up? Well it's started by the kernel when it is loaded. It is called init. Init's behaviour is controlled by the runlevels described above. It's what starts the login getty stuff, it starts up all the services and if you have it go to runlevel 5 it will start the gui login stuff, too. (xdm, gdm, kdm, whatever).
The file /etc/inittab controls the scedualing. You can fire up the text editor and view the file and can even edit it to change init's behavior, but I wouldn't recommend trying it from there.
In your /etc/rc.d/ directory you have several more directories. Each corisponding to a specific runlevel. It will execute the scripts in those directories depending on the runlevel.
So runlevel 3 will execute every file in the /etc/rc.d/rc3.d/ and runlevel 0 will run every script in directory /etc/rc.d/rc0.d/.
(Another example. I use Slackware. In slack I don't have any /etc/rc.d/rc3.d/ directories. I only have a /etc/rc.d/rc.M file. Inittab tells init to execute /etc/rc.M when it reaches runlevel 3 and rc.M has several if/then statements looking for different files that specificly designed to start up different services and such. A bit simpler, but requiring more manual intervention so that install script by unsupported programs won't be able to set up it's runlevel as easily as in Redhat and most other distros. For me though I like it. I recently added "mpg321 /home/drag/.muzak.mp3" on the tail end of my rc.M file to play some soothing acid jaz music every time I boot-up)
Now usually when you install services in redhat using rpms it will plop a script in the /etc/init.d directory. So if you install sendmail, it will put a sendmail script in the /etc/init.d. Now part of the install creates a symbolic link from the /etc/rc.d/rcX.d to the corrisponding script in the /etc/init.d directory. (Symbolic links are like "shortcuts" or pointers to files located elseware. You can make links using the "ln -s" command.)
Normally the command chkconfig will show you how the whole /etc/rc.X and /etc/init.d stuff is set up. And you can use it to set which script starts at which runlevel. It will take care of all the symbolic links and handle that stuff so you don't have to. If you can I would just use that command to take care of everything, but sometimes it isn't enough.
Now I don't know how you install vnc or what command is needed to start the server up.
If you installed it using a rpm, make sure that the server is set to start up when the graphical login stuff starts in runlevel 5. If you had to install it by some other means, it is pretty likely that it will still set up the different runlevel stuff for you, but if it didn't you may need to make your own script and put it in the /etc/rc.d/rc3.d directory.
A simple bash script can look like the following. Lets pretend that once you install vnc it will put a executable file in the /usr/local/bin file called vncstart. Of course this probably isn't the correct name and location of the command to actually start vnc server, but hopefully you get the idea.
#! /bin/sh
# start vnc here:
/usr/local/bin/vncstart
And that would be about it. Just don't forget to make the script executable if it needs to be. (the command would be "chmod 744 scriptname") If you know sh scripting you can add if then statements to do checking to make sure that it will start up properly and stuff, or to set up some extra things you may like to have associated with vnc) but this should be enough. Once you get everything configured and set up you can use the "telinit q" command to have init reload itself and hopefully it will set up your vnc correctly.
You should check out the "man" files on different things: inittab init runlevel shutdown kill.
to help fill in the blanks on what is needed to do. Also read any documentation about the vnc version you are installing and find out if you can acually set it up to start from init, or can it only be executed from the X session after you login and stuff. Also check out
this page. This is what I used to fill in my blanks about Redhat. I suppose Redhat will have a nifty gui config tool that you can use to establish runlevels and scripts and crap, but I think it's helpfull to understand what's going on in the background. Also check out Redhat's website and see if you can find any info on runlevels and stuff to automate starting up services.
Now if that crap all works out, you aught to be able to just plug it into the wall, turn it on, and it will automaticly set up vnc for you.
Hope that helps.
Facebook
Twitter