Please don't flame me if this is something silly, of if there is already something that could do it and I did not know. ip-up receives the ipparam when it is called. It could be used to add a custom initialization procedure for users which have several ppp connections, where adding stuff to ip-up could cause problems to other ppp connections. Reproducible: Always Steps to Reproduce: 1. have two or more ppp connections 2. need to add custom stuff to ip-up for one connection, but which should not be used by any other conection Actual Results: changing ip-up alters all ppp connections Expected Results: ip-up should handle custom stuff for each ppp connection graciously Forgive me for not providing proper patches, I am just dabbling into this stuff. If we add the following to ip-up: ----- [ -f /etc/ppp/ip-up.$1 ] && . /etc/ppp/ip-up.$1 "$@" ----- it could gracefully handle stuff in teh file called ip-up.ppp0 for connection ppp0, ip-up.ppp1 for ppp1, and so on, without one interfering with the other. teh same coule be done for ip-down: ----- [ -f /etc/ppp/ip-down.$1 ] && . /etc/ppp/ip-down.$1 "$@" ----- It could also bear some comment to explain this stuff: ----- #If you need other custom settings to happen after the connection is up, #create a file named ip-up.pppX in /etc/ppp. ip-up will automatically #call it, if it exists. ----- For ip-down, I think it would be something like this: ----- #If you need other custom settings to happen after disconnecting, #create a file named ip-down.pppX in /etc/ppp. ip-down will automatically #call it, if it exists. -----
just a reminder: I am waiting the results also, I see there is a /etc/init.d/rp-pppoe script. maybe it is best to use it.
ah .. sorry about comment #1 I've made a confusion
but there is already a script for customize ip-up/ip-down, namely ip-up.local/ip-down.local. If you like, you could create a ip-up.local with something like: #!/bin/sh dev=$1 shift [ -f /etc/ppp/ip-up.$dev ] && . /etc/ppp/ip-up.$dev "$@" I see no point in running yet another custom script called ip-up.ppp0, when the first parameter passed to it _is_ ppp0
Yeah, I have seen that. My point is that some people might have more than one or two ppp connections and Gentoo should provide an easy way to set up custom settings. According to the ppp man pages, ip-up is the official place for custom stuff. It's like you are splitting ip-up in two pieces, by having a second file hard named ip-up.local being called from ip-up. No offense intended, but I think it's kind of pointless. Maybe you could replace ip-up.local with ip-up.$dev, because different devices are likely to have different custom settings, and it would save the users from adding a code to ip-up.local to check if the connection being brought up is the right one (this could be done on ip-up anyway, why doing it on a different file?). It would be already implied to which connection the script belongs to. IMHO, having ip-up.$dev is better than ip-up.local
none taken. this design is borrowed from other distros (debian I believe). I also think it is the right thing to do (users should have the possibility of running their own common script on startup of ppp connections + the fact that $1 parameter would be redundant). besides, if we do that, what would go first: ip-up.local or ip-up.ppp0? This decision should be taken by sysadmin, you must agree with me. if you run your scripts in current bash process (prefixing script names by . or source), the overhead is really tiny.
hmm, ip-up.local has a point to exist after all. I have a (several) question(s) then: The ppp man pages state that ip-up is the right place for custom stuff, so the Gentooist way is to do stuff on ip-up.local and leave ip-up alone? If there are many distros doing this, would it make sense to push it upstream? Or is the man page out of date?
from a gentooist point of view, ip-ul.local is the user script because updates don't affect it (no need to run etc-update/dispatch-conf for merging the 2 versions). from upstream point of view, ip-up is the user script. they don't know/care how distros use their package. after all, man page is correct; ip-up is the right place. first step when you customize a script is to open it and see what it contains. you don't need more than 3 seconds to realize it could call another custom script, don't ya?
