User-Agent: Build Identifier: Attached is a portage branch for the new beta release of the no-ip updater. Reproducible: Always Steps to Reproduce:
Created attachment 7773 [details] portage branch net-dns/noip-updater-2.0.6b Debatable whether or not to actually label it noip-updater-2.0.0_beta6
emerged 2.0.6b on my machine, the service starts and stops proper unlike the 1.6 version. Also digging how the /etc/no-ip2.conf is not palin text like the no-ip.conf for 1.6 was. can't test for iif it actually updates the ip addresses for hosts until I actually have an ip address change, but will comment on it jsut as soon as I do, hopefully in the next day or 2 I'll be buying another nic, and that'll gimme a new ip addy when I setup NAT and ip forewarding
Can't comment about the new no-ip2.conf. My bet is that it is encrypted. Maybe not. It is also root read-only. Not the same for no-ip.conf though... The noip-1.6 not stopping problem is strictly my fault. I had some quirky code to kill noip instead of start-stop-daemon. Also, the dependency on net was not strong enough in some cases...
ok, not sure if this is normal, but when noip-updater service is stopped, it sets the redirects for any dns host to 0.0.0.0, i guess it thought I was shutting down the system, and if I had restarted it I assume it woulda changed em back. will test more
Very well then, but even as I speak, 2.06b has been deprecated in favour of 2.0.10. The ebuild will work, renamed.
Updated as net-dns/noip-updater-2.0.12
this should be renamed to noip to follow gentoo conventions. this noip-updater should be deprecated, if not removed entirely. i actually went ahead and made an ebuild myself and optimized some of the issues. namely, i optimized the build process so it doesn't need patches (inline sed editing instead), and also let the compiler use the make.conf's $CFLAGS. another "issue" was the /etc/init.d runscript. my version is much simpler and less interactive (as an init script should be). it won't bring you to the configuration questions. also... i got rid of the resetting to 0.0.0.0 address in the stop() portion. it involves no-ip.com keeping a saved state of the client's ip address. the thing is, the suggested init script in the README.FIRST file doesn't do this (and i really can't see what the benefit is), so why do it in ourn? heh.
Created attachment 14175 [details] my portage branch for noip # tar ztf noip-razamatan.tgz noip/ noip/Manifest noip/files/ noip/files/digest-noip-2.0.12 noip/files/noip.runscript noip/noip-2.0.12.ebuild
Mine is not interactive... Only when idiot users forget to configure, then it starts asking questions. Just like the seti@home script. As for the setting to 0.0.0.0 , the people using a noip service are most likely to be a home user, therefore, if they shut down the computer, it is feasible to assume it will not be available for some time. I think that noip is not descriptive enough... Inline sed editing is messy and is slower. Spawning a process 4 times isn't exactly faster than spawning 1 process. I disagree on the runscript dependencies. noip depends on DNS to resolve the address of the server to contact.
seems you're doing a lot of defense... my apologizes... my intention wasn't to attack your ebuild, but try to conform it a little... > Mine is not interactive... Only when idiot users forget to configure, then it starts > asking questions. > Just like the seti@home script. well.. this is usually going to be run as an init script... i've always approached init scripts as scripts that should only output 2 things: success messages and error messages. if the user forgets to configure noip, then when the computer boots up, it shouldn't stall the boot process waiting for user input. instead, any good init script should just spew forth helpful error messages so that when the system is up, the sysadmin can do his/her thing and configure it. > As for the setting to 0.0.0.0 , the people using a noip service are most likely to > be a home user, therefore, if they shut down the computer, it is feasible to assume > it will not be available for some time. setting the ip to 0.0.0.0 might be better served inside of /etc/conf.d/local.stop or something like that to handle this scenario. honestly, i removed the 0.0.0.0 business b/c noip works fine w/o it, less bandwidth, and including it in the runscript might get a few questions headed your way. like it did here. > I think that noip is not descriptive enough... this one... hmm... well.. i think it is descriptive enuf.. considering that an emerge -s will get ppl the url of the package... the main point is that "noip" conforms to what is suggested for package names... the package is called noip, not noip-updater > Inline sed editing is messy and is slower. Spawning a process 4 times isn't exactly > faster than spawning 1 process. inline sed is definately not messy and is very fast for trivial changes to files. this way, the gentoo mirrors have one less file transaction to handle (no patch) and it makes the ebuild easier to upgrade (don't have to recreate patches). i could have made it two sed statements (using the -e switch), but decided to keep each expression on its own line for readability. in terms of runtime, we're dealing w/ milliseconds, whereas a wget to a gentoo mirror is only as good as your connection to the mirror. > I disagree on the runscript dependencies. noip depends on DNS to resolve the address > of the server to contact. sure. btw... the current ebuild doesn't use /etc/make.conf's CFLAGS... having packages use your /etc/make.conf's CFLAGS is big for optimization. i like gentoo b/c of the CFLAGS business.
Yes, I see your logic now. Jared, REOPEN please?
