* J C Vollmer [Nov 24. 2001 21:19]:

...

I cannot find a way of automatically starting an X program. Is there an equivalent to the Startup folder in Windows.

I have read that you can put an entry in init.d but that does not work. I am using the syntax /path/programname

is that correct or should you use some other form, and if init.d does not work, is there a better place to put the command. The command as I have written it works from an X terminal.

You can use the Autostart directory.

You can find it in $HOME/.kde2/Autostart

Just put your script in there (or a link to it) and it will run when your Xsession starts.

But that only works with KDE. I have something like this in my .xinitrc: sleep 1 && $HOME/bin/slit start & sleep 3 && xmms & exec blackbox Which makes sure they get started after the windowmanager is up and running. -- Mads Martin Joergensen, http://mmj.dk "Why make things difficult, when it is possible to make them cryptic and totally illogic, with just a little bit more effort." -- A. P. J.

* David [Nov 25. 2001 02:21]:

Thanks all for your replies, but it is not working

I do not have a $HOME directory, and hence no Autostart. I have edited the /home/.initrc file and enclose the last few lines of the file showing my entry. Where am I going wrong?

# start some stuff NEXT LINE IS MY ENTRY /usr/local/bin/firestarter start

Try /usr/local/bin/firestarter start & -- Mads Martin Joergensen, http://mmj.dk "Why make things difficult, when it is possible to make them cryptic and totally illogic, with just a little bit more effort." -- A. P. J.

An update on the non progress. I have been poking around in Konqeror file manager and noticed an Autostart option. This creates an autostart folder and was able to put firestarter into it - and it works. Well that is the good bit. The bad is that although it loads and works, Netscape crashes (surprise!!), and the Konqueror browser is not able to go anywhere. So it seems it is not a good idea to have Firestarter start first. It has been suggested somewhere to load it in ip-up. This does not work, but I notice from the xconsole read out that it does not load up this file. Extract below. Nov 25 14:12:37 linux kernel: IN=eth0 OUT= MAC= SRC=192.168.0.2 DST=192.168.0.255 LEN=234 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=138 DPT=138 LEN=214 Nov 25 14:13:24 linux /etc/ppp/ip-up: ip-up: Loading of module ipchains was not successful. Nov 25 14:13:24 linux /etc/ppp/ip-up: Aborting. No action taken. Nov 25 14:13:25 linux kernel: IN=ppp0 OUT= MAC= SRC=195.92.195.94 DST=217.135.223.102 LEN=246 TOS=0x00 PREC=0x00 TTL=63 ID=45317 PROTO=UDP SPT=53 DPT=1038 LEN=226 This is the standard file produced by Suse and all references to ipchains are commented out. Any ideas on this. Regards, David On Sun, 25 Nov 2001 02:22:13 +0100, Mads Martin Jørgensen wrote:

* David [Nov 25. 2001 02:21]:

Try

/usr/local/bin/firestarter start &

-- Mads Martin Joergensen, http://mmj.dk "Why make things difficult, when it is possible to make them cryptic and totally illogic, with just a little bit more effort." -- A. P. J.

I just installed Hubert's .15 kernel and the .15 kernel told me on boot that I shouldn't load the ipchains.o because it taint's the kernel and that it has a non-GPL license and that it's a BSD license. I also loaded the NVdriver that I linked to the .15 kernel. This was the message I got when I did that. "Warning: loading /lib/modules/2.4.15-4GB/kernel/drivers/video/NVdriver.o will taint the kernel: no license" WTF is this.. So every non-kernel 3rd party driver will taint the kernel? Oh brother. The press will have a field day with this. I thought that the ipchains module was a Linux thing. BSD uses ipfilter most of the time. I could be wrong..but this was the impression I got. Cheers, -----=====-----=====-----=====-----=====----- Ben Rosenberg mailto:ben@whack.org -----=====-----=====-----=====-----=====----- "Technological progress is like an axe in the hands of a pathological criminal" -AE

On Sun, 25 Nov 2001 21:51:49 +0000 David wrote:

Hi Geoff,

I thought it was your suggestion.

Yes I have found that faq and done that, but it doesn't work. Firestarter works with chains or tables. I don't see what there is in ip-up that is asking for ip-chains and do not understand why it does not read the rest of the file. I have tried putting it at the front but it does not seem to

like it - stalls.

I notice that on the original ip-up the kinternet log gives ................ ip-up failed (return value 0xff00)

No clear answer I am afraid David, but with regard to the following extract from the log you posted previously ... Nov 25 14:13:24 linux /etc/ppp/ip-up: ip-up: Loading of module ipchains was not successful. Nov 25 14:13:24 linux /etc/ppp/ip-up: Aborting. No action taken. ... I found a post on the on suse-security list which may be relevant and which I will quote in full below - it might at least eliminate a red herring, but I am afraid that I really don't know enough about firewalls to say. Maybe another approach would be to initialise Firestarter from an /etc/ppp/ip-up.local script ? At least that would isolate it. Mind you, according to the section 23 of the PPP HOWT0 : Ip-up is just a shell script and can do anything that a shell script can do (i.e. virtually anything you want). For example, you can get sendmail to dispatch any waiting outbound messages in the mail queue. Similarly, you can insert the commands into ip-up to collect (using pop) any email waiting for you at your ISP. There are restrictions on /etc/ppp/ip-up:- **It runs in a deliberately restricted environment to enhance security. This means you must give a full path to binaries etc.*** Maybe, therefore, you should give the full path to Firestarter ? Geoff Here is the post from the security list. Date: Fri, 5 Oct 2001 12:09:46 +0200 (MEST) From: Roman Drahtmueller Message-ID: Subject: Re: [suse-security] SuSEfirewall2 & ipchains?!

I finally got around to switching to SuSEfirewall2. Installation and setup were straightforward, and my testing sems to indicate it's doing what I expect...

However, I'm now seeing the following messages in /var/log/messages as I bring up, and again as I terminate a ppp session (using kppp):

/etc/ppp/ip-down: ip-down: Loading of module ipchains was not successful. /etc/ppp/ip-down: Aborting. No action taken.

This output is from the SuSEpersonal-firewall (which works with ipchains in SuSE-7.2 only). It tried to load the ipchains module, which does not work if the iptables framework has been loaded before. SuSEfirewall and SuSEpersonal-firewall can work together, but SuSEfirewall2 needs iptables. By consequence, you must disable the SuSEpersonal-firewall in /etc/rc.config.d/security.rc.config (Set REJECT_ALL_INCOMING_CONNECTIONS="no"). SuSE-7.3 comes with a personal-firewall package that can work with both iptables and ipchains. None of the scripts should remove modules from a running kernel since this is inherently racy, and SuSEpersonal-firewall does not remove modules at all. SuSEfirewall2 does, the version in 7.3 is a bit more careful and will not remove loaded iptables modules any more because of the likelyness of a kernel crash (fixed in the last beta phase of 7.3).

A search of /etc/ppp/ip-up, ip-up.local, and SuSEFirewall2 shows the only reference to the ipchains module is an attempt to `rmmod` it. Is this message simply an obfuscated way of saying that it couldn't be removed because it wasn't loaded?

No, the other way around. Please add a line for SuSEfirewall2 to ip-up that resembles the one for SuSEfirewall so that the fw-script is being executed upon dial-in. Thanks, Roman. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

Thanks Geoff for your research You prompted me to look at my Suse f/w again. I downloaded the Suse2 f/w the other day, clicked on install and nothing happened, had a look at the script and didn't go any further. However looking again I see it has installed itself, disabled Suse1 and enabled Suse2, but it didn't copy ip-up across. I have done that and it removes the error messages for ip-up. If I put in a line for firestarter, incidentally I always put the full path, I get the ip-up error in the kinternet log. That was putting it at the end. I have tried the ip-up.local but it is ignored. Tried putting it into ip-up, but again ignored. Does ip-up.local need to be set as a particular file type? I see in ip-up there is a line to check for ip-up.local and run if possible. So I assume my syntax is wrong, but it runs from the x terminal. Maybe it needs to be started later, but I don't know what follows on from that. Thanks David On Mon, 26 Nov 2001 16:26:00 +0000, Geoff wrote:

No clear answer I am afraid David, but with regard to the following extract from the log you posted previously ...

Nov 25 14:13:24 linux /etc/ppp/ip-up: ip-up: Loading of module ipchains was not successful. Nov 25 14:13:24 linux /etc/ppp/ip-up: Aborting. No action taken.

.... I found a post on the on suse-security list which may be relevant and which I will quote in full below - it might at least eliminate a red herring, but I am afraid that I really don't know enough about firewalls to say.

Maybe another approach would be to initialise Firestarter from an /etc/ppp/ip -up.local script ? At least that would isolate it. Mind you, according to the section 23 of the PPP HOWT0 :

Ip-up is just a shell script and can do anything that a shell script can do (i.e. virtually anything you want).

For example, you can get sendmail to dispatch any waiting outbound messages in the mail queue.

Similarly, you can insert the commands into ip-up to collect (using pop) any email waiting for you at your ISP.

There are restrictions on /etc/ppp/ip-up:- **It runs in a deliberately restricted environment to enhance security. This means you must give a full path to binaries etc.***

Maybe, therefore, you should give the full path to Firestarter ?

Geoff

Here is the post from the security list.

Date: Fri, 5 Oct 2001 12:09:46 +0200 (MEST) From: Roman Drahtmueller Message-ID: Subject: Re: [suse -security] SuSEfirewall2 & ipchains?!

...

I finally got around to switching to SuSEfirewall2. Installation and setup were straightforward, and my testing sems to indicate it's doing what I expect...

However, I'm now seeing the following messages in /var/log/messages as I bring up, and again as I terminate a ppp session (using kppp):

/etc/ppp/ip-down: ip-down: Loading of module ipchains was not successful. /etc/ppp/ip-down: Aborting. No action taken.

This output is from the SuSEpersonal-firewall (which works with ipchains in SuSE-7.2 only). It tried to load the ipchains module, which does not work if the iptables framework has been loaded before. SuSEfirewall and SuSEpersonal -firewall can work together, but SuSEfirewall2 needs iptables. By consequence, you must disable the SuSEpersonal-firewall in /etc/rc.config.d/security.rc.config (Set REJECT_ALL_INCOMING_CONNECTIONS="no").

SuSE-7.3 comes with a personal-firewall package that can work with both iptables and ipchains. None of the scripts should remove modules from a running kernel since this is inherently racy, and SuSEpersonal-firewall does not remove modules at all. SuSEfirewall2 does, the version in 7.3 is a bit more careful and will not remove loaded iptables modules any more because of the likelyness of a kernel crash (fixed in the last beta phase of 7.3).

...

A search of /etc/ppp/ip-up, ip-up.local, and SuSEFirewall2 shows the only reference to the ipchains module is an attempt to `rmmod` it. Is this message simply an obfuscated way of saying that it couldn't be removed because it wasn't loaded?

No, the other way around.

Please add a line for SuSEfirewall2 to ip-up that resembles the one for SuSEfirewall so that the fw-script is being executed upon dial-in.

Thanks, Roman.

_________________________________________________________

Do You Yahoo!?

Get your free @yahoo.com address at http://mail.yahoo.com

Thanks Geoff Just checking. Is there a space after chmod and after +x. I assume you mean ip-up not ip.up. How do I know if the file has changed its type. I cannot see any change in its properties. Incidentally, where, how or what calls Netscape up. Can't find where it is called from. Regards, David On Tue, 27 Nov 2001 08:11:48 +0000, Geoff wrote:

Hi David,

ip-up.local needs to be executable .. have you done that?

I think you need to create /etc/ppp/ip.up.local as root then :

chmod +x /etc/ppp/ip.up.local

Regards,

Geoff

_________________________________________________________

Do You Yahoo!?

Get your free @yahoo.com address at http://mail.yahoo.com

Hi Geoff This is becoming a bit of a saga :) below On Wed, 28 Nov 2001 19:55:08 +0000, Geoff wrote:

I am not sure exactly where you are checking the properties, but if you "ls -l ip-up.local" you should see a string of letters and dashes on the left side of the output. The fourth one in from the left will change from a dash to an x when you make the file executable.

Ok it is an exex

If you want to make the file into a pukka shell script the full format is :

#!/bin/bash # Insert here the comment of your choice to remind you what the file is for. # /full/path/to/firestarter > /home/<username>/dampsquib 2>&1 &

If you want a simple test to check whether the file ever executes, you could put the following line before the line that runs firestarter :

touch /home/username/testiplocal

Done that - now getting dampsquib created. The file contains the following Gtk-WARNING **: cannot open display. Can't find testiplocal. So although that command works on the command line, something is not right in the file ??

That will just create a new empty file, testiplocal, of 0 length in your home directory, which (as root), you can then delete. Its creation will prove that ip-up.local executed, and the contents of /home/<username>/dampsquib will show any messages generated by firestarter.

If all this eventually works, then we may need to think about creating an ip -down.local which will terminate firestarter until it is next needed, ... but it feels like tempting fate to go into that now. I love your optimism :)

...

Incidentally, where, how or what calls Netscape up. Can't find where it is called from.

I do not make much use of Netscape. I believe, however, that when you invoke Netscape the call is to /usr/X11R6/bin/netscape. That is a symlink to the shell script /usr/X11R6/bin/communicator, which contains a variety of tests and commands. To tell the truth, I have never bothered to get to the bottom of that script. That might be an interesting diversion for a rainy afternoon (then again it might not). I might be wrong about all this though.

No, I pointed you to the wrong end. Where is it being called from, I thought maybe wvdial.conf. I tried it there but no go. But maybe I should concentrate on ip-up.local since we now know it is being read. Thanks Regards, David

Hi Geoff

No problem. I like a saga. I shall sign myself Noggin the Nog henceforth >:- ). I like that

I am baffled by the testiplocal output. However, because we only put the line in the script as a test that it is being executed, and the existence of dampsquib proves that it is, I suggest that you just edit out the line.

The "Gtk-WARNING **: cannot open display" is interesting. I have a theory that the problem may be that the script is trying to open a window in your display but, because it runs as root, it is not being allowed access to your X display. Current versions of X come with a high level of security.

I suggest therefore that you do the following :

(1) Delete the existing dampsquib .. or make sure that you see a new creation date when next you dial up your ISP.

(2) Before you next dial your ISP enter the command You do this as yourself, not as root. You should see : "access control disabled, clients can connect from any host". Root can now access your display and, if we are in luck, the "Gtk-WARNING **: cannot open display" may go away.

(3) Connect to the ISP and re-examine dampsquib.

No didn't change anything It is strange. If I watch the kinternet log and load firestarter when ip-up is called it works fine - fathom that! I can't run from user. Firestarter stops me saying I have to be root. There is a problem somewhere, but I sure don't know where. Maybe I will re install it.

I understand. I use wvdial so I know it is not that. I agree that you should stay with ip-up.local for the time being.

Thanks Regards, David

Hi Geoff On Fri, 30 Nov 2001 17:28:01 +0000, Geoff wrote:

Just checking ... by "didn't change anything" you mean that dampsquib still reports "Gtk-WARNING **: cannot open display" - correct?

I think that was my mistake. I was assuming that # would rem lines out. When I removed all the # lines it did not re appear.

It seems that ip-up is never completing, even when we move the firestarter stuff into the ip-up.local script - which is not entirely surprising if there is some problem starting firestarter from the script. The easy test for the correctness of that is to try to log on to your ISP when ip-up.local has failed. Presumably you can't and also presumably running ifconfig does not reveal the presence of ppp0.

Assuming that when Firestarter is called from local and does not start is a failure, then the connection proceeds and is firewalled. As I understand it, it falls back to the Suse firewall. When F/s loads it replaces Suse.

Who owns the firestarter executable? ls-l /full/path/to/firestarter should give the answer (second column of the output). If it is root then you could, as root, . That should allow other users to run it. If the owner is not root, then and then .

ls-l /full/path/to/firestarter That gives command not found, however I would expect it to be root since you cannot access Firestarter from user. In the file properties from Konqueror it show Ownership as root for User and Group.

...

...

I don't suppose that there is any harm in reinstallation - though the cynical money is on it making no difference.

You are probably right, but sometimes it works. Have you ever taken items apart when they don't work - can't find anything wrong, but start it and it works.

Keep smiling, there *is* a way to do this.

Yes, I've got it selotaped in position :) Thanks Regards, David

Hi Geoff

To the best of my knowledge, # is a definite rem. The problem you have, and the one you had with the touch command, makes me wonder what software you are using to create your shell scripts. It has to be a text editor (such as kedit), not any kind of word-processor (such as kwrite? I forget the name). A shell script has to be pure ASCII and embedded control codes in word-processor files screw things up.

No, not that, I use the basic text editor, kedit I think.

...

In the file properties from Konqueror it show Ownership as root for User and Group.

OK .. I should have put the space in ls[space]-l - that would work.

...

...

...

...

I assumed one was missing, but I missed that option. As I said above, it is root.

...

...

I don't suppose that there is any harm in reinstallation - though the cynical money is on it making no difference.

You are probably right, but sometimes it works. Have you ever taken items apart when they don't work - can't find anything wrong, but start it and it works.

True - I have also found the converse to be true. Being an engineer, taking things apart is usually high on the list :)

Don't think I will tackle it today. Have been up all night with a sick horse and am not feeling my best now. Thanks Regards, David

On Sat, 1 Dec 2001 14:27:13 +0000 Geoff wrote:

On Sat, 1 Dec 2001 12:02:12 +0000 David wrote:

Dratted cut and paste ... obviously in my earlier post the line "access control disabled, clients can connect from any host" should come after ... I think that you will have to enter my command before you go online. Remember that you enter that as your own username and you should see .. not lower down the page. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

On Thu, 6 Dec 2001 00:58:07 +0000 David wrote:

Hi Geoff Got Firestarter back up again - ok I can here the groan.

No groans - except of sympathy.

I put your ip-up.local in, and if I run it directly it loads Firestarter, but not when called from ip-up, though in the kinternet log it shows that ip-up

was

successfull. It is being called in ip-up by

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # call ip-up.local if it exists and is executable: test -x /etc/ppp/ip-up.local && /etc/ppp/ip-up.local "$@" ;; ip-down)

# Restore the nameservers (got with ipppd option ms-get-dns): ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Is this correct, or does it need altering.

That looks correct to me - it is identical to mine.

...

"access control disabled, clients can connect from any host"

should come after ...

I think that you will have to enter my command before you go

online.

...

Remember that you enter that as your own username and you should see

OK .. time for a little theory. Your X server identifes its displays by two numbers, starting with 0:0. When you start a server you get ownership of a display, starting with the 0:0 default. This becomes part of your "environment". If you enter whilst running an X session you will see the value of that default display. There is a security check which stops other people from accessing your display without permission. Thus if you are running an X session as <username> and you su to root and try to run something that uses X then you will see access denied - or some equivalent message. You can give others permission to access your display in various ways. The quick and dirty way is which simply kills the security and lets anyone in. There are better and more secure ways which do not involve you in typing every time, but there is no point in setting those up until we know that it helps. The ip-up.local script runs as root. When first you tried it dampsquib reported the Gtk error that the display could not be opened. I thought that this was a problem that could be cured by , but that turned out not to be the case, and if you were running X as root I suppose that should not be surprising, because I think that in those circumstances root would own display 0:0. When I installed F/s I was running as my own <username> and I had used to allow root access to the display. Even so, I saw the self-same Gtk "could not open display" error in my dampsquib. A little research showed that this is a known problem and that root needs to have a display set as part of his environment to cure it. All that my ip-up.local does is to set root's environment to use 0:0. It worked immediately and I ran about 20 tests without fail. Now, if you are running everything as root, I would not expect the export line in my ip-up.local to make such a difference - because root already owns the display. I therefore went back and did some experiments this morning, using my old unloved kde setup as root. Here is what I found : (1) Root must still execute before the first attempt to contact the ISP. (2) This cures the cannot access display problem *but* there is another problem, which, because of an accident in the sequence of events when I ran my tests last Saturday, did not then arise. It seems to be linked to an aspect of gnome (not exactly sure which yet), that ip-up.local has problems starting. Before I work out a fix, will you please test that your system behaves the same way as mine, so far, by carrying out the following protocol : (a) Reboot (b) Enter and confirm that the response is : "access control disabled, clients can connect from any host" (c) Logon to your isp and start F/s by hand from the command line. The aim here is to initialise the bits of gnome that it needs and which can apparently be started from the command line but which ip-up.local does not yet initialise. This seems to be a once and for all process which will last until you next restart X. (d) Close F/s and logoff from your isp. (e) Logon to your isp again. In my system that will have the result that F/s starts automatically from ip-up.local. If it is the same for you, then we just have to work on a fix for the gnome thing. Regards, Geoff _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

On Thu, 6 Dec 2001 23:09:16 +0000 David wrote: <snip>

Now we differ. Yes F/s starts up automatically, but the system appears to freeze, it hasn't but it is extremely slow, to the extent that it takes about 30 secs to bring any window to the front. On the kinternet log it gets as far as pppd secondary address DNS xxx.xxx.xx.xxx and stays like that, then I get pppd terminating due to lack of activity and it disconnects. The system is then back up to speed, except for F/s that takes forever to repaint its window, 30 secs +. It seems that F/s is slowing the system loading it this way.

Rebooting and doing it manually, if I load F/s just after ip-up has run, then it will prevent the browser connecting. If I stop it and get the browser going, start F/s (this is just using the stop start buttons) then it is fine.

Have you set yours for masquerading?

My arrangements are simple but a little unusual in that I run VMware because I have no other choice than to use the Devil's Own OS for some stuff. I allow the virtual Win98 machine running within my linux box to access the outside world by masquerading, but the whole arrangement is of my own devising - the words Robinson and Heath spring to mind (though not necessarily in that order). Dampsquib shows F/s complaining about a whole lot of missing stuff, but I look upon its discomfort with a certain sadistic satifaction, because my only aim has been to get it to show its miserable face by running ip-up.local rather than procuring that it should work as advertised in any other respect. Joking apart, I certainly do not see any of the symptoms you describe and I imagine that there must be some interaction between the SuSE firewall, F/s and netscape that is causing the problem (it does not take Donald Knuth to work that one out). Now that you know what is autoloading Netscape, I would personally be very tempted to see what effect it would have to stop that autoload from taking place. If, however, you actually need Netscape to autoload I understand that the intellectual satisfaction might not be worth the effort.

As an alternative solution, I have found where in Yast2 Netscape is loading. I

want to put Netscape & firestarter to load one after the other. Can you load 2

programs on one line? I tried netscape; firestarter. This loads netscape, and when it is shut down loads firestarter, not quite what I want.

By a quirk of language, your question may contain your answer. Try the command . That should start Netscape as a background job and allow continue on to start F/s. That is on the assumption that what you see in YAST2 (I don't have it), is just a simple command line (or something that works the same way). I do, however, have one reservation, as follows. Netscape takes a while to complete loading. The command I have suggested may actually initialise F/s before Netscape has got its boots on, which may mean that the problem is not cured. We can cross that bridge (by using a more elaborate command), if and when we come to it. Regards, Geoff _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

On Sat, 8 Dec 2001 13:21:34 +0000 David wrote:

...

Dampsquib shows F/s complaining about a whole lot of missing stuff, but I look upon its discomfort with a certain sadistic satifaction, because my only aim has been to get it to show its miserable face by running ip-up.local rather than procuring that it should work as advertised in any other respect.

It's only a machine, and as such is getting masochistic pleasure from its lack

of sensation from your onslaught - but is only a machine - so it can't :)

Well, I can at least hope that it gets a terrible pain in all the diodes down its left side. <snip>

Well 'netscape & firestarter' does work. They load in the correct order and function correctly. The drawback is that on re connection new copies of each are loaded again, they still work though. Presumably I need to create a batch file to load them with something of the sort 'if exist don't load'.

I will have some fun using that as a five finger exercise in scripting (If some killjoy doesn't beat me to it). I will get back to you post dinnner and a drop of single malt. Regards, Geoff _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

Hi Geoff On Sat, 1 Dec 2001 14:27:13 +0000, Geoff wrote:

I hope you (and the horse) are rested.

Thanks for that. The poor boy was in a bad way. Had to get the Vet out in the middle of the night - I'll look forward to that bill coming in :(

Curiosity got the better of me. I compiled and installed firestarter. I saw your problem and I think I *may* have fixed it. It works for me.

Unfortunately the cavalry arrived after I surrendered. Had to do something, so I uninstalled Firestarter, then deleted all f/s files and directories. Thought I would have a nice clean sheet. So you know when you take things apart, put them together and they look fine, but don't work anymore. That's where I am. Can't even get the Suse f/w to work. F/s is uninstalled. Have taken out Suse f/w, iptables, ipchains, put them all back, and still no working f/w. Can't work it out. I have done it before and it worked. Must be missing something somewhere. I know F/s must have a working f/w before you can install it.

I have written a new ip-up.local, and, just in case there is problem with your shell scripting, I am also going to send it as an attachment by private email. You will need to make it executable as you did before.

I appreciate that. As soon as I can get this working again I will try it.

I think that you will have to enter my command before you go online. Remember that you enter that as your own username and you should see It it works, there will, in due course, be a more refined way of doing things. I think that you will have to enter my command before you go online. Remember that you enter that as your own username and you should see :

access control disabled, clients can connect from any host

Then go online.

Regards,

Geoff

_________________________________________________________

Do You Yahoo!?

Get your free @yahoo.com address at http://mail.yahoo.com

Regards, David

Hi Geoff On Mon, 3 Dec 2001 07:57:30 +0000, Geoff wrote:

The words Murphy, Law and double-dratt spring to mind.

Shows what a good guy you are - never thought of using those words :)

It is really hard for me to offer any constructive advice there. As I have said, I am not very well-versed if firewalling, and I did the absolute minimum just to get the F/s window to appear so that I could play with the non -starting problem. Maybe a separate post to the List will produce an answer if all else fails.

Yes I have done that - I'll see what happens

I am reasonably confident that it will work. Don't forget the xhost + when the time comes.

It is all noted - I'll keep you posted Regards, David

I have tried it as root and as user - no difference. Regards, David On Sat, 24 Nov 2001 19:31:04 -0600, Jerry Kreps wrote:

How did you log in? If you logged in as root your $HOME is /root. If you logged in as <user> your $HOME is /home/<user> Just curious. Jerry

...

# start some stuff NEXT LINE IS MY ENTRY

/usr/local/bin/firestarter start #

...

# day planer deamon # pland &

# # finaly start the window manager # exec $WINDOWMANAGER

#

# call failsafe exit 0

Regards,

David

On Sat, 24 Nov 2001 21:58:56 +0100, Mads Martin Jørgensen wrote:

...

* J C Vollmer [Nov 24. 2001 21:19]:

...

You can use the Autostart directory.

You can find it in $HOME/.kde2/Autostart

Just put your script in there (or a link to it) and it will run when your Xsession starts.

But that only works with KDE.

I have something like this in my .xinitrc:

sleep 1 && $HOME/bin/slit start & sleep 3 && xmms & exec blackbox

Which makes sure they get started after the windowmanager is up and running.

-- Mads Martin Joergensen, http://mmj.dk "Why make things difficult, when it is possible to make them cryptic and totally illogic, with just a little bit more effort." -- A. P. J.

Ok thanks. That explains it. I though that existed as a physical directory. Still no Autostart though. Can one be created manually? Regards, David On Sun, 25 Nov 2001 00:40:13 -0500, Joshua Lee wrote:

Everyone has a $HOME directory. The $ means it's an environment variable. $HOME is a directory with the name the variable HOME contains. This variable is automatically set to be the directory you get when you first login or open a terminal window, typically /home/name or for root /root. For example, when I log in as edlin, my home directory is /home/edlin. When one is in the shell in another directory, one go back by typing cd ~, and you get your $HOME directory.

This may sound silly, but because Linux is a multiuser operating system this actually is very useful, as it is then possible for a programmer to access configuration files that individual users this multiuser OS have changed without knowing beforehand each individual's login directory by name. Therefore making individual configuration more flexable.

On Sunday 25 November 2001 07:18 am, you wrote:

...

shell in another directory, one go back by typing cd ~, and you get your $HOME directory.

You can also simply type "cd" to land in your $HOME directory.

You learn something new everyday. :-) Thanks.