Re: racoon and bug 372665
Hello Milan, Milan P. Stanic [EMAIL PROTECTED] wrote: On Sun, Mar 04, 2007 at 06:36:34PM +0530, Ganesan Rajagopal wrote: Milan P Stanic [EMAIL PROTECTED] writes: I'd like to discuss problem with regards to bug #372665. Why the racoon should be started in the rcS when even ssh is not? The reasons should be fairly obvious from the bug. IPsec is at a much lower level than ssh. racoon needs to come up before other network dependent services get started. README says that in the /etc/rcS.d/ should go scripts which are executed once during boot. In debian policy manual rcS.d is mentioned only once in section 9.3.4, but from short description it is not clear could the daemons be started from scripts in that directory. I like to add that starting a daemon in /etc/rcS.d/ causes troubles when switching later to runlevel 1 (e.g. for maintenance) and coming back to the real runlevel (e.g. 2). The script /etc/init.d/killprocs started as /etc/rc1.d/S30killprocs kills these daemons started in runlevel S. They are never started again and you may get a broken system, when you came back to your default runlevel. I had/have this problem with devfsd very often. Regards, Jörg. -- Ich halte ihn zwar für einen Schurken und das was er sagt für falsch – aber ich bin bereit mein Leben dafür einzusetzen, daß er seine Meinung sagen kann.(Voltair) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: racoon and bug 372665
On Mon, Mar 26, 2007 at 05:05:53PM +, Jörg Sommer wrote: Milan P. Stanic [EMAIL PROTECTED] wrote: README says that in the /etc/rcS.d/ should go scripts which are executed once during boot. In debian policy manual rcS.d is mentioned only once in section 9.3.4, but from short description it is not clear could the daemons be started from scripts in that directory. I like to add that starting a daemon in /etc/rcS.d/ causes troubles when switching later to runlevel 1 (e.g. for maintenance) and coming back to the real runlevel (e.g. 2). The script /etc/init.d/killprocs started as /etc/rc1.d/S30killprocs kills these daemons started in runlevel S. They are never started again and you may get a broken system, when you came back to your default runlevel. I had/have this problem with devfsd very often. The decision to start daemons from /etc/rcS.d/ is made by presumptions that the sysvinit is the *only* init subsystem in Debian. Ganesan didn't take to account that this will break running racoon under runit which is packaged in Debian as alternative init subsystem. I understand why he wants to start racoon so early in boot process but (IMO) that shouldn't lead to breakage of the another init subsystem. The reason could be because policy is vague in that case. Would it work under upstart I don't know because I don't have enough time to test it excessively but it looks like it works without problem. [ I'm just playing with upstart ] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: racoon and bug 372665
Hello Milan, Milan P. Stanic [EMAIL PROTECTED] wrote: On Mon, Mar 26, 2007 at 05:05:53PM +, Jörg Sommer wrote: Milan P. Stanic [EMAIL PROTECTED] wrote: README says that in the /etc/rcS.d/ should go scripts which are executed once during boot. In debian policy manual rcS.d is mentioned only once in section 9.3.4, but from short description it is not clear could the daemons be started from scripts in that directory. I like to add that starting a daemon in /etc/rcS.d/ causes troubles when switching later to runlevel 1 (e.g. for maintenance) and coming back to the real runlevel (e.g. 2). The script /etc/init.d/killprocs started as /etc/rc1.d/S30killprocs kills these daemons started in runlevel S. They are never started again and you may get a broken system, when you came back to your default runlevel. I had/have this problem with devfsd very often. The decision to start daemons from /etc/rcS.d/ is made by presumptions that the sysvinit is the *only* init subsystem in Debian. Can't raccon be started like wpa_supplicant by an ifup command? You can start the wpa_supplicant by bringing up the interface: ,[ /etc/network/interfaces ]--- | iface eth1 inet manual | wpa_roam /etc/wpa_supplicant.conf | wpa_driver wext ` Bye, Jörg. -- Computer Science is no more about Computers than astronomy is about telescopes. (Edsger Wybe Dijkstra) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: racoon and bug 372665
Jörg == Jörg Sommer [EMAIL PROTECTED] writes: Can't raccon be started like wpa_supplicant by an ifup command? You can start the wpa_supplicant by bringing up the interface: ,[ /etc/network/interfaces ]--- | iface eth1 inet manual | wpa_roam /etc/wpa_supplicant.conf | wpa_driver wext ` racoon is not a per-interface daemon, so I don't think that will work. -- Ganesan Rajagopal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: racoon and bug 372665
On Wed, Mar 07, 2007 at 07:17:00AM +0530, Ganesan Rajagopal wrote:
Milan == Milan P Stanic [EMAIL PROTECTED] writes:
I don't think so (except maybe udev, but servers can happily work without
udev). What is the reason to start nfs from one time initialization
subsystem? Portmap and nfs can be started in runlevel 2 to 5.
That's debatable. However current Debian policy as per /etc/rcS.d/README is
=
The following sequence points are defined at this time:
* After the S40 scripts have executed, all local file systems are mounted
and networking is available. All device drivers have been initialized.
* After the S60 scripts have executed, the system clock has been set, NFS
filesystems have been mounted (unless the system depends on the automounter,
which is started later) and the filesystems have been cleaned.
=
Yes, it is true. But is also says that:
=
The scripts in this directory whose names begin with an 'S' are executed
once when booting the system, even when booting directly into single
user mode.
=
Look at are executed once. Daemons could be executed once when booting
the system but also could be stopped, started and restarted during normal
server (or workstation) operation.
Besides NFS, if your entire access to the network requires IPsec, you cannot
even ssh outside the box unless racoon sets up a tunnel. It's really a
critical service in that sense.
So could be other VPN subsystems (OpenVPN, VPNC, SSH etc).
I would think that mountnfs.sh should be moved somewhere else
(/etc/rc{2-5}.d/) where portmap have symlinks already. If we mount
remote filesystems so early why samba is not started from /etc/rcS.d/ ?
Policy is ambiguous (at least) here, IMO.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: racoon and bug 372665
On Tue, Mar 06, 2007 at 11:02:35AM +0530, Ganesan Rajagopal wrote: Milan == Milan P Stanic [EMAIL PROTECTED] writes: Some daemons _need_ to be started from /etc/rcS.d (udev for example). Another good example is portmap for nfs. If you're mounting nfs volumes over IPsec then, racoon needs to start to setup the IPsec tunnel. I don't think so (except maybe udev, but servers can happily work without udev). What is the reason to start nfs from one time initialization subsystem? Portmap and nfs can be started in runlevel 2 to 5. What if someone mount nfs over ppp tunneled through ssh? Should we than stard sshd from /etc/rcS.d/? What's with other VPN daemons like OpenVPN, VPNC, TINC ...? My mistake. I should say boot process. Sorry for inconvenience. I understood that. I am still not clear why it would interfere with the boot process. I'll try to reproduce it under UML at the weekend. That was with racoon patched to work under runit (or other supervisor software like daemontools). When I reinstalled racoon from testing it doesn't block booting process. But that gives mi a hint. If some daemon process could not be started (for whatever reason) it should not block the booting. racoon should come up just fine even if it fails to negotiate any tunnels. Any way, the default policy does not even setup any tunnels. As I said in previous post it was my mistake. racoon comes up fine. The problem is in that if it is started from /etc/rcS.d/ when runit tries to start racoon it fails because racoon is running already. Let me know if you're still stuck; I can try your patches in a test setup with runit when I find some time. I'll post patch to ipsec-devel list (you are subscribed, IIRC) in a few days (I want to test it a little) but if you want tell me and I will send ti to you in private mail. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: racoon and bug 372665
Milan == Milan P Stanic [EMAIL PROTECTED] writes: On Tue, Mar 06, 2007 at 11:02:35AM +0530, Ganesan Rajagopal wrote: Some daemons _need_ to be started from /etc/rcS.d (udev for example). Another good example is portmap for nfs. If you're mounting nfs volumes over IPsec then, racoon needs to start to setup the IPsec tunnel. I don't think so (except maybe udev, but servers can happily work without udev). What is the reason to start nfs from one time initialization subsystem? Portmap and nfs can be started in runlevel 2 to 5. That's debatable. However current Debian policy as per /etc/rcS.d/README is = The following sequence points are defined at this time: * After the S40 scripts have executed, all local file systems are mounted and networking is available. All device drivers have been initialized. * After the S60 scripts have executed, the system clock has been set, NFS filesystems have been mounted (unless the system depends on the automounter, which is started later) and the filesystems have been cleaned. = Besides NFS, if your entire access to the network requires IPsec, you cannot even ssh outside the box unless racoon sets up a tunnel. It's really a critical service in that sense. Ganesan -- Ganesan Rajagopal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: racoon and bug 372665
On Sun, Mar 04, 2007 at 06:36:34PM +0530, Ganesan Rajagopal wrote: Milan P Stanic [EMAIL PROTECTED] writes: I'd like to discuss problem with regards to bug #372665. Why the racoon should be started in the rcS when even ssh is not? The reasons should be fairly obvious from the bug. IPsec is at a much lower level than ssh. racoon needs to come up before other network dependent services get started. README says that in the /etc/rcS.d/ should go scripts which are executed once during boot. In debian policy manual rcS.d is mentioned only once in section 9.3.4, but from short description it is not clear could the daemons be started from scripts in that directory. Yesterday I installed racoon but not configured it and on the next reboot it blocked start-up process. I had to manually remove /etc/rcS.d/S40racoon to boot machine. This should not happen. What do you mean blocked the start-up process? My mistake. I should say boot process. Sorry for inconvenience. That was with racoon patched to work under runit (or other supervisor software like daemontools). When I reinstalled racoon from testing it doesn't block booting process. But that gives mi a hint. If some daemon process could not be started (for whatever reason) it should not block the booting. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: racoon and bug 372665
Milan == Milan P Stanic [EMAIL PROTECTED] writes: README says that in the /etc/rcS.d/ should go scripts which are executed once during boot. In debian policy manual rcS.d is mentioned only once in section 9.3.4, but from short description it is not clear could the daemons be started from scripts in that directory. Some daemons _need_ to be started from /etc/rcS.d (udev for example). Another good example is portmap for nfs. If you're mounting nfs volumes over IPsec then, racoon needs to start to setup the IPsec tunnel. Yesterday I installed racoon but not configured it and on the next reboot it blocked start-up process. I had to manually remove /etc/rcS.d/S40racoon to boot machine. This should not happen. What do you mean blocked the start-up process? My mistake. I should say boot process. Sorry for inconvenience. I understood that. I am still not clear why it would interfere with the boot process. That was with racoon patched to work under runit (or other supervisor software like daemontools). When I reinstalled racoon from testing it doesn't block booting process. But that gives mi a hint. If some daemon process could not be started (for whatever reason) it should not block the booting. racoon should come up just fine even if it fails to negotiate any tunnels. Any way, the default policy does not even setup any tunnels. Let me know if you're still stuck; I can try your patches in a test setup with runit when I find some time. Ganesan -- Ganesan Rajagopal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
racoon and bug 372665
I'd like to discuss problem with regards to bug #372665. Why the racoon should be started in the rcS when even ssh is not? Yesterday I installed racoon but not configured it and on the next reboot it blocked start-up process. I had to manually remove /etc/rcS.d/S40racoon to boot machine. I didn't posted bug report because of above mentioned bug (which introduced this bad behavior, IMO) before someone who understand boot process, shed a little more light on that problem. I'm using runit instead of sysvinit as init process but I think that doesn't invalidate my complaint. signature.asc Description: Digital signature
Re: racoon and bug 372665
Milan P Stanic [EMAIL PROTECTED] writes: I'd like to discuss problem with regards to bug #372665. Why the racoon should be started in the rcS when even ssh is not? The reasons should be fairly obvious from the bug. IPsec is at a much lower level than ssh. racoon needs to come up before other network dependent services get started. Yesterday I installed racoon but not configured it and on the next reboot it blocked start-up process. I had to manually remove /etc/rcS.d/S40racoon to boot machine. This should not happen. What do you mean blocked the start-up process? Ganesan -- Ganesan Rajagopal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
