Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
However, the bulk of the start up is in the "init scripts". Unlike autoexec.bat there are separate scripts for different purposes. You'll have one for most every subsystem or application.
The base init scripts are in /etc/init.d.
However, the start up and stop of each init script is done by putting links to the init scripts in the run level directories such as /dev/rc1.d (single user, /dev/rc2.d - /dev/rc5.d (multi-user run levels) and specialized run levels. The naming of the linked files will be S##.... for start and K##... for stop.
Setting these up takes a bit more work than autoexec.bat. You can find all sorts of information by doing Google search for "init script" or "what happens when linux boots".
For Fedora/RedHat/CentOS there is a command called chkconfig that can be used to show or set which run levels specific init scripts are turned "on" (started" or "off" (stopped). Typing "man chkconfig" will give you information about the usage of that command.
Hmm, I suspected it to be a wee bit more complex that the old autoexec. The whole thing is arond Dazuko. I cannot "insmod" it, because annother security module does'nt like it, I quote from the FAQ @ Dazuko's themselves
In /var/log/messages it says "kernel: There is already a security framework initialized, register_security failed. kernel: dazuko: failed to register". What is wrong?
This occurs because another security module is already loaded and is not allowing Dazuko to be loaded. In order to allow multiple security modules, Linux 2.6 supports stacking. Unfortunately some modules do not implement this, which makes it impossible to load additional security modules. Dazuko does support stacking correctly. If you make sure that Dazuko is the first loaded security module, than other modules can also be loaded.
Typically the problem is the "capability" module. You can verify that this is the problem by unloading the "capability" module, loading Dazuko, and then reloading the "capability" module:
If this was indeed the problem, you can usually configure your system to load modules in a specific order. This varies between Linux distributions.
--------- End Quote -----------------------------
Now, placint Dazuko a bit "earlier" in the loading process could then allow me to insert the module without bothering the rest. Unless I have to insert the three lines (testlines) into a Script - somewhere...
OK modules are a completely different animal not part of the init stuff.
Modules are loaded by the kernel.
They're essentially telling you to update /etc/modprobe.conf (2.6 kernel) or /etc/modules.conf (2.4 kernels). You need to follow the instructions they provided carefully as this affects how your system boots.