On 5/18/06, Peter Van Lone wrote:

On 5/18/06, Per Jessen wrote:

...

Uh, rerun the brctl commands at boot-time? Bascially insert the proper script into your startup sequence or add them to the standard SUSE network-startup.

lol! (following is a 'mini-thread-hijaak' ...)

Per, you make that sound so simple! I am struggling to make sense of how to simply "insert the proper script into your startup sequence".

It seems there are a bunch of directories where a script COULD go ... is there a good HOW TO anywhere on SUSE startup? One of the things I'm finding with linux is that each and every procedure has SO MANY options/things you can do, and the docs all go into ALL of the options, that it is simply over-whelming to figure out how to do simple things. I would LOVE a simple HOW TO on SUSE startup procedures/commands/scripts. Something short of 50 pages that could help me to organize my understanding of the architecture ...

When is it OK to just put startup commands into /etc/init.d/boot.local?

Which rc#.d location is the correct one? /etc/init.d/rc#.d? Or, /etc/rc.d/rc#.d?

To create a script in /etc/init.d/rc3.d, do I just give it a K# or S# name, and then type in whatever commands are used to start the program? Or, is there a syntax that has to be followed?

What is the role of /etc/sysconfig?

Is there a procedure for integrating a startup routine with the YAST runlevel editor?

I'm not sure that boot.local is good for you, as it runs before any runlevel is entered, i.e. before network is started. At least this is my understanding. Although running my firewall script (build with fwbuilder) works OK from boot.local, so maybe I'm wrong. Anyway - the proper way is to make a copy of /etc/init.d/skeleton script to a new name (again in init.d) and modify it to make it run after network is up, etc. The script is well documented, so you should be able to figure it out. After you are ready with your script you can use either chkconfig to set the right runlevels, or you can use Yast/System/Runlevel editor to enable it. This will create the proper K and S links in the right rc directories. Cheers -- -- Svetoslav Milenov (Sunny) Windows is a 32-bit extension to a 16-bit graphical shell for an 8-bit operating system originally coded for a 4-bit microprocessor by a 2-bit company that can't stand 1 bit of competition.

On Thu, 2006-05-18 at 10:03 -0500, Peter Van Lone wrote:

On 5/18/06, Sunny wrote:

...

After you are ready with your script you can use either chkconfig to set the right runlevels, or you can use Yast/System/Runlevel editor to enable it. This will create the proper K and S links in the right rc directories.

so having the script in /etc/init.d allows the runlevel editor to see/use it? And then the runlevel editor (or chkconfig) then creates the K and S sym links in the right places? (is that right?)

Cool ... so, skeleton is .... not straight forward ... but get that figured out, and I'm golden. Cool, thnx!

It's not quite as simple as that. Look at the following: ### BEGIN INIT INFO # Provides: FOO # Required-Start: $syslog $remote_fs # Should-Start: $time ypbind sendmail # Required-Stop: $syslog $remote_fs # Should-Stop: $time ypbind sendmail # Default-Start: 3 5 # Default-Stop: 0 1 2 6 # Short-Description: FOO XYZ daemon providing ZYX # Description: Start FOO to allow XY and provide YZ # continued on second line by '#<TAB>' # should contain enough info for the runlevel editor # to give admin some idea what this service does and # what it's needed for ... # (The Short-Description should already be a good hint.) ### END INIT INFO You need to figure out and provide the proper # Required-Start: # Should-Start # Required-Stop: # Should-Stop: # Default-Start: # Default-Stop: These are required in order to have your script start (and stop) in the proper order from the other scripts. But it is not as difficult as it looks. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998

On Thu, 2006-05-18 at 10:55 -0500, Peter Van Lone wrote:

On 5/18/06, Ken Schneider wrote:

...

It's not quite as simple as that. Look at the following:

yes, I am studying skeleton right now, trying to get a handle on it. It looks as though, for most services, the "required start/stop" and "should start/stop" are pretty straight-foreward. Does the local file system need to be up? Does a remote file system need to be up? Does the network need to be up? etc ...

I am a little confused about whether every section HAS to be done for each service you want to start. For example:

# Check for missing binaries (stale symlinks should not happen) # Note: Special treatment of stop for LSB conformance FOO_BIN=/usr/sbin/FOO test -x $FOO_BIN || { echo "$FOO_BIN not installed"; if [ "$1" = "stop" ]; then exit 0; else exit 5; fi; }

# Check for existence of needed config file and read it FOO_CONFIG=/etc/sysconfig/FOO test -r $FOO_CONFIG || { echo "$FOO_CONFIG not existing"; if [ "$1" = "stop" ]; then exit 0; else exit 6; fi; }

# Read config . $FOO_CONFIG

Do I HAVE to do this testing for each service? And, what if the service/program does not have a particular config file? Or, what if the service finds it's config file on it's own? Do I still need to complete this section? Or, can I comment it all out?

The best thing to do is to look at the other scripts in /etc/init.d and use them as examples for your script. If there is no config file for your script you can delete or comment out that part of your script. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998

On 18/05/06 10:17, Per Jessen wrote:

/Per Jessen, Zürich PS: sometimes I leave out the exact details - after all, it's a learning exercise, so if I gave away the answers right away, well .... :-)

But already you're too late; Rui Santos as you can see has already stolen the entire jar of cookies =-O

On 19/05/06 03:51, Rui Santos wrote:

Darryl Gregorash wrote:

...

On 18/05/06 10:17, Per Jessen wrote:

...

/Per Jessen, Zürich PS: sometimes I leave out the exact details - after all, it's a learning exercise, so if I gave away the answers right away, well .... :-)

But already you're too late; Rui Santos as you can see has already stolen the entire jar of cookies =-O

Ok. I assume I interpreted the first email on this thread the wrong way. I Thought Drew Burchet had a problem he couldn't solve and wanted to if someone had a script already made... sorry for that...

No, you didn't interpret it the wrong way; what I meant by my rather cryptic note was that you posted the solution (or at least a very good basis for one) before Per began his lesson :-)

Ken Schneider wrote:

On Fri, 2006-05-19 at 10:51 +0100, Rui Santos wrote:

...

Darryl Gregorash wrote:

...

On 18/05/06 10:17, Per Jessen wrote:

...

/Per Jessen, Zürich PS: sometimes I leave out the exact details - after all, it's a learning exercise, so if I gave away the answers right away, well .... :-)

But already you're too late; Rui Santos as you can see has already stolen the entire jar of cookies =-O

Ok. I assume I interpreted the first email on this thread the wrong way. I Thought Drew Burchet had a problem he couldn't solve and wanted to if someone had a script already made... sorry for that... Anyway, The script I provided is far from perfect... for instance: smbd starts first than setbridge on SuSE10.0, wich causes problems to samba. There should be others... It can, and should, be evolved.

If you add your setbridge script to the # Required-Start: line in /etc/init.d/smb the start order of the scripts will change so that samba starts -after- your script.

Thanks... It worked... -- Rui Santos http://www.ruisantos.com/ They that would give up essential liberty for temporary safety deserve neither one of them.