net-dns/ddclient-3.6.7 version bump
A few bugs solved and a few new dynamic dns providers added.
Tried this with a simple version bump of ebuild from bug #91500 -- seems to work just fine.
Works for me. Just changing the name of the ebuild and manually downloading the package worked.
Michael, was it necessary to manually download the package? emerge'ing the bumped version of the ebuild should automatically download the source.
I'm going to do some work on this app, so I want to make some notes here that I think are related to 3.6.7 getting into portage: Changes that *aren't* recorded in the tarball's Changelog: - Did Arun's Patches from bug 91500 get integrated upstream: - ddclient-cfgprotect.diff - YES - ddclient-cachefix.diff - NO - ddclient-normalexit.diff - NO Everything else, it's either in the changelog or your guess is as good as mine. Arun, did upstream ever explain to you why the permissions were handled that way? As far as I can tell ddclient works just fine if you remove the bizarre permissions checks altogether, and just make sure the conf file is readable. I'm tempted to remove that block of code.
(In reply to comment #4) Yes, portage 404'd every time. Here are my mirrors: GENTOO_MIRRORS="http://mirror.datapipe.net/gentoo http://open-systems.ufl.edu/mirrors/gentoo http://prometheus.cs.wmich.edu/gentoo http://www.mirrorservice.org/sites/www.ibiblio.org/gentoo/ http://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/ http://gentoo.mirrors.pair.com"
(In reply to comment #6) > (In reply to comment #4) > > Yes, portage 404'd every time. Here are my mirrors: I'm not sure how SRC_URI="mirror://sourceforge/..." works, but shouldn't it just pull in the package from an SF mirror? (In reply to comment #5) > Changes that *aren't* recorded in the tarball's Changelog: The 3.6.7 version doesn't include any of our changes ... > - Did Arun's Patches from bug 91500 get integrated upstream: > - ddclient-cfgprotect.diff - YES Ummm...I don't see this in 3.6.7. Are you sure? The bug is at http://sourceforge.net/tracker/index.php?func=detail&aid=1328268&group_id=116817&atid=676128 > - ddclient-cachefix.diff - NO wimpunk's aiming for this in 4.0.0 -- http://sourceforge.net/tracker/index.php?func=detail&aid=1372687&group_id=116817&atid=676128 > - ddclient-normalexit.diff - NO No comments yet -- hope to see something soon http://sourceforge.net/forum/forum.php?thread_id=1358013&forum_id=399428 > Everything else, it's either in the changelog or your guess is as good as mine. I guess each of these needs to be taken up upstream if required. For example, most people would probably be okay with putting their config in /etc. We need the ddclient subdirectory since we're putting the example config in there too. I'm not too sure about the daemon0 and mss1 patches.
Created attachment 77501 [details] Proposed ebuild for 3.6.7 This ebuild for 3.6.7 incorporates Arun's changes from 3.6.6 (bug 91500). I also made a single line change myself, to include the next attachment.
Created attachment 77502 [details] Proposed initscript for 3.6.7 This initscript includes Arun's USR1 signal, but uses the username "ddclient" instead of a pid to find the process to kill. Please note this fixes a bug that the pid can sometimes be wrong. I didn't report that bug, because I fixed it here :-)
Created attachment 77503 [details, diff] Permissions patch for 3.6.7 After some discussion with various people in and around #gentoo I came to the conclusion that ddclient shouldn't be changing permissions on anything. This alters the perl script so that it gives a gives a warning if the permissions are wrong, but as long as it can read the config file, it should work.
Created attachment 78780 [details, diff] Combined patch for 3.6.7 This integrates all the previous patches and fixes ddclient so it gracefully accepts USR1 again. It seems to work on my machine; I would appreciate some testing. On another note: There is still a minor problem with the permissions. My fix makes ddclient give warnings when it sees files with owns other than root:ddclient and perms other than 0640. Unfortunately I didn't realize it warns for /var/run/ddclient/* files, as well. grr... Anyway, it all works, it just puts cruft in the logs. I'll look at it again later.
Comment on attachment 78780 [details, diff] Combined patch for 3.6.7 Changed name to prevent confusion, and to go with the ebuild patch I'm submitting.
Created attachment 78781 [details, diff] Combined ebuild patch for ddclient-3.6.7.ebuild This is a patch to convert *ddclient-3.6.6.ebuild* into ddclient-3.6.7.ebuild. The resultant ebuild refers to ddclient-3.6.7-combined.patch to upgrade the perl source code.
Created attachment 78782 [details, diff] Patches the 3.6.6 init file This patch file converts the 3.6.6 init file that's already in portage to work with Arun's USR1 signal and ddclient's internal pidfile handling.
take them, Diego
x86 team, can y'all test this set of stuff and confirm arun's fixes for me please?
all the patches apply cleanly and ddclient works as intended.
removing x86
Created attachment 84063 [details] ddclient-3.6.7.ebuild Here is a nice and simple ebuild which works. It uses the initscript from comment #9 as "ddclient.init", and that's the only file it needs in $FILESDIR. It has the following desirable properties: * It fixes the maddening permissions for users automatically. This is *very* important. * It does not create contradictory error messages regarding the permissions of "/var/run/ddclient/ddclient.cache", as the patch in comment #11 does. * It only trivially changes the ddclient source code, so revision bumping will be easy.
I think it's ~bad~ that ddclient (the ebuild, not the program) changes the permissions on files. This is the job of a sysadmin, not software. It's understandable that the ebuild would set the correct permissions at install time, but if the wacko user wants to change them, he should be able to, without ddclient going back and undoing the change. Security problem? Yes, ddclient.conf might contain a cleartext password, but security is, again, the responsibility of the sysadmin. This was the point of the patch in comment #10. However, the fact that I allowed the sysadmin to control permissions meant I had to warn him he was being stupid. That was the cause of the minor bug in comment #11, which I admittedly never fixed. There's no good/easy solution, but how many daemons flip out when you modify their files' permissions? Not too many (as long as they can read the file), and many of them are far more security-critical than ddclient. (I note that ddclient was originally written by a fellow named Paul Burry. Paul Bredbury seems like a fairly similar name -- any relation?)
Sorry, very tired. I meant the program, not the ebuild!
The idea that *fixing* permissions for users in an ebuild is the wrong thing to do, is alien to me. Especially with the seemingly ultra-strict rules in ddclient. Users do *not* want an upgrade to break, and scratch their head for a couple of hours while the init script shouts the unhelpful "!!" at them. They want the ebuild to just fix it. That's the point of an ebuild - to do all the obvious setup automatically. If I wanted to run chown and chmod myself, then I might as well go all the way and wget ddclient from sourceforge and run "make" myself. I suspect that most people using this ebuild would call themselves "users" rather than "sysadmins". Sysadmins are expected to have done all this a million times already, and know exactly how to fix it with minimum downtime for their precious clients. Users want to get it working and get to the pub :) Gentoo ebuilds are not written for wackos, they are written for the sane majority who have a fairly sane configuration. Wackos can create their own variations on the ebuilds (as I have done), for their weird setups. The permissions will only be changed if they are "wrong"-ish. Nope, no relation, but I did a double-take as I was browsing through the Debian changelog, to see how Debian do it :) My newbie installation instructions for the ebuild, for anyone who wants ddclient to *just work*, are at http://forums.gentoo.org/viewtopic-p-3236622.html#3236622
(In reply to comment #22) > The idea that *fixing* permissions for users in an ebuild is the wrong thing to > do, is alien to me. Me, too. That was a typo -- hence comment #21. I meant that the *program* shouldn't mess with permissions, not the ebuild.
Created attachment 84068 [details] ddclient-3.6.7.ebuild Fixed installation of sample configuration file.
(In reply to comment #23) > I meant that the *program* shouldn't mess with permissions, not the ebuild. Ah OK, sorry, I'm with you, finally. I misinterpreted comment #10, thinking it referred to the ebuild. So, to be clear, it's the job of the ebuild to fix the ridiculously obvious and tediously necessary permissions, since we're not all elite sysadmins. Agreed? :)
(In reply to comment #25) > it's the job of the ebuild to fix...permissions. Agreed? Agreed. By the same coin, it's *not* the job of the initscript or the program itself. Agreed?
(In reply to comment #26) > By the same coin, it's *not* the job of the initscript or the program > itself. Agreed? Agreed. Groovy :)
Created attachment 84237 [details] ddclient.init Changed the initscript back to using a pidfile, which is now specified completely within the initscript. What's the pid bug mentioned in comment #9?
Created attachment 84238 [details] ddclient-3.6.7.ebuild Now removes the redundant pid line from the sample config file.
(In reply to comment #28) > What's the pid bug mentioned in comment #9? Some versions of the initscript used start-stop-daemon to specify the pidfile, but originally the pidfile wasn't specified by ddclient.conf. Then you get: # /etc/init.d/ddclient stop * Stopping DDClient ... start-stop-daemon: warning: failed to kill 21702: No such process 1 pids were not killed No process in pidfile `/var/run/ddclient/ddclient.pid' found running; none killed. [ !! ] because the pidfile is wrong. The pidfile specified either by the config file *or* by command-line to ddclient is fine, as long as the pidfile used to kill ddclient is the same. Your method is an improvement, Paul, because it doesn't break if the user changes the config file. It would be even more ideal if the initscript could get the user's preferred pidfile out of the config file. (I think it's more "gentoo-like" when the user can change stuff.)
Created attachment 84416 [details] ddclient-3.6.7.ebuild Now allows the PIDFILE to be changed in /etc/conf.d/ddclient, for the tiny proportion who actually want to change it :)
Created attachment 84417 [details] ddclient.confd
Created attachment 84418 [details] ddclient.initd
Sorry for the delayed reply. (In reply to comment #25) > (In reply to comment #23) > > I meant that the *program* shouldn't mess with permissions, not the ebuild. > > So, to be clear, it's the job of the ebuild to fix the ridiculously obvious and > tediously necessary permissions, since we're not all elite sysadmins. Agreed? > :) I disagree with this change. It is not okay to *silently* change permissions of a file that a user might have set explicit perms on. You can do either of two things: 1) Fix the perms in the ebuild if required, and issue an 'ewarn' stating that this was done 2) Just issue a warning telling the user clearly what (s)he must do I prefer the second by far -- it is less intrusive, and I do not believe the system needs to be dumbed down to the extent that option 1 is required. We issue the exact commands to be run clearly -- there is no question of the user "scratching his head for 2 hours". OTOH, saying "if the behaviour you prefer requires a minor deviation from the standard install, maintain your own ebuild" does seem rather inflexible.
I've just added the ability to change the pidfile location. Adding an ewarn is fine. *What* deviation is my ebuild preventing? With option 2, you might as well say: "1: download from sourceforge. 2: Run "make install. 3: Set up the permissions yourself." Ho hum. An ebuild that tells me that it's left me to run some perfectly straightforward commands, leaves me scratching my head wondering why the ebuild didn't just go ahead and get that tediousness done itself. Does Gentoo allow the deviation of relocating e.g. /etc/init.d and /etc/conf.d? There have to be sane limits on the "flexibility" allowed, otherwise all ebuilds could be judged inflexible.
(In reply to comment #35) <snip> > With option 2, you might as well say: "1: download from sourceforge. 2: Run > "make install. 3: Set up the permissions yourself." Ho hum. I think it's a big jump from asking the user to change permissions on a file *once* to what you're talking about. > An ebuild that tells me that it's left me to run some perfectly straightforward > commands, leaves me scratching my head wondering why the ebuild didn't just go > ahead and get that tediousness done itself. Because doing it automatically might break the setup of someone who does not use the default setup. Look at it this way -- if my setup is different, everytime I update ddclient, I need to change my setup. If I'm happy with the default setup, I just need to change permissions *once*. One example of a deviation from the default setup might be a user who has a single user (say 'dummy') for all apps that need a separate user like ddclient does. Don't know if this a real-world example -- I just cooked it up. The point I am trying to make is that we should not make life that much more difficult just because a user has a slightly different setup. > Does Gentoo allow the deviation of relocating e.g. /etc/init.d and /etc/conf.d? > There have to be sane limits on the "flexibility" allowed, otherwise all > ebuilds could be judged inflexible. Sure there are limits. We just seem to disagree with regards to what the limits are. :)
(In reply to comment #36) > The point > I am trying to make is that we should not make life that much more difficult > just because a user has a slightly different setup. So, for the sake of one sysadmin who has a non-standard installation, we should inconvenience the other 99% who just want ddclient to install and work? The ones using stable Portage probably won't even see the ewarn. This is policy which is skewed in favour of the rare customization done by someone who should know what he's doing. I'm saying that we should be skewing the user-friendliness of the ebuilds in favour of the new user who *isn't* a Gentoo expert. I think there is one solution which will make us both happy, which is to finish off the patch to prevent the Perl script from being security-paranoid and moaning/dying when it doesn't see the exact permissions setup that it expects.
(In reply to comment #37) > So, for the sake of one sysadmin who has a non-standard installation, we should > inconvenience the other 99% who just want ddclient to install and work? The > ones using stable Portage probably won't even see the ewarn. This is policy > which is skewed in favour of the rare customization done by someone who should > know what he's doing. I'm saying that we should be skewing the > user-friendliness of the ebuilds in favour of the new user who *isn't* a Gentoo > expert. 1) Changing permissions (especially when the exact command to be run) requires no Gentoo expertise, and only a basic understanding of UNIX 2) Following ewarn output is difficult on stable, but there is no excuse for ignoring it 3) The inconvenience is a minor, one-time thing (I do understand the rationale behind your argument, but the odd exception should be okay, I think) > I think there is one solution which will make us both happy, which is to finish > off the patch to prevent the Perl script from being security-paranoid and > moaning/dying when it doesn't see the exact permissions setup that it expects. What do you think the solution should be? We really should continue to issue a warning if the file is world-readable. Adequate security paranoia is a Good Thing.
Whoops ... (In reply to comment #38) > 1) Changing permissions (especially when the exact command to be run) requires > no Gentoo expertise, and only a basic understanding of UNIX (especially when the exact command to be run is provided)
Created attachment 84435 [details] ddclient-3.6.7.ebuild (In reply to comment #38) > 2) Following ewarn output is difficult on stable, but there is no excuse for > ignoring it I use PORTAGE_ELOG, so I'm happy. But, refer to the Gentoo Apache Idiocy thread, for the amount of flak received from the attitude that newbies should heed a warning which flies up and off the screen at the speed of light: http://forums.gentoo.org/viewtopic-t-384368.html > We really should continue to issue a > warning if the file is world-readable. Adequate security paranoia is a Good > Thing. Indeed. This next version changes the paranoia level from hairpin-trigger to merely nervous. Now I need to go wash my hands after touching Perl code :)
Created attachment 84436 [details, diff] ddclient-reasonable-security.patch Makes the security behaviour regarding the config file sensible - it dies if the config file is accessible in any way by world, otherwise it's happy.
(In reply to comment #40) > Created an attachment (id=84435) [edit] > ddclient-3.6.7.ebuild > > (In reply to comment #38) > > 2) Following ewarn output is difficult on stable, but there is no excuse for > > ignoring it > > I use PORTAGE_ELOG, so I'm happy. But, refer to the Gentoo Apache Idiocy > thread, for the amount of flak received from the attitude that newbies should > heed a warning which flies up and off the screen at the speed of light: Before PORTAGE_ELOG, I redirected all output to a file and searched through for messages after the emerge. Mildly painful, but much better than missing the warnings. Anyway, the changes look okay, except that the pkg_postinst() seems to have disappeared from the latest ebuild -- maybe we should do the permissions check upfront in the ebuild as well, rather than waiting till the user restarts?
(In reply to comment #42) > Anyway, the changes look okay, except that the pkg_postinst() seems to have > disappeared from the latest ebuild -- maybe we should do the permissions check > upfront in the ebuild as well, rather than waiting till the user restarts? pkg_postinst() is not needed, with the Perl script patched to have sane security checks. Ebuilds do not, in general, go checking all the security settings of the installed files - they install sane default permissions, and so any changes are by the user (ahem, "sysadmin"), who is supposed to only make security changes if he knows what he's doing. Doing the check in the ebuild would just be a duplication of effort. A sysadmin who makes security changes, then doesn't even check whether the program *starts* without error, doesn't fall into the category of "knows what he's doing". :)
Sheesh. I go to sleep and you guys argue all night :-P. I started to patch the perl (see commment #11), but it's still buggy, putting cruft in the log files when the pidfile's permissions are off. (AFAICT that's the only bug.) (In reply to comment #41) > It dies if > the config file is accessible in any way by world, otherwise it's happy. Here we are again. I *still* think the user should be *able* to do stupid things like make the config file world readable. Warn the living tar out of him, but don't kill ddclient over it. My patch makes ddclient warn about bad permissions, and tell the user how to change them, but doesn't actually do anything or prevent ddclient from working. The only permissions condition that would break ddclient would be if the uid running ddclient can't read the config file. Does this really need to be this complicated? Let me review what *I* think we want. 1) Default permissions: - On first install, we want ddclient.conf to install root:ddclient with 0640 permissions. - On CONFIG_PROTECTed installs we want ddclient.conf untouched. 2) Running ddclient: - If the ownership and permissions are root:ddclient 0640, then everything runs fine. - If the ownership and permissions are different, but readable by ddclient, then ddclient warns, but runs anyway. (How it should warn [ddclient/sterr/log/init] is debatable) - If the config file is not readable by ddclient, then the initscript fails to start ddclient. (It would anyway, but maybe we can make this failure user-friendly with a sensible error message.) Did I miss anything? Oh, yes, my bug. I think pidfiles are created each time the initscript starts, so we can set the permissions at --start time, right?
Created attachment 84466 [details] ddclient-3.6.7.ebuild In *what* situation would making ddclient.conf world-readable be a good idea? It contains a password. Also, we don't want to check the permissions too carefully, otherwise the one crazy guy per 100 sysadmins is gonna complain that he can't run it as the user named after his dog, in the group named after his budgie. Or something. The pidfile gets "-rw-r--r-- ddclient ddclient" permissions automatically, so no change is needed. I like the "root:ddclient with 0640" idea - here's another update.
Created attachment 84467 [details, diff] ddclient-reasonable-security.patch Suggests 0640 rather than 0600 permissions.
(In reply to comment #45) > In *what* situation would making ddclient.conf world-readable be a good idea? It doesn't have to be a good idea, just one that some user might actually want. You and I are arguing orthogonal points. I'm saying we shouldn't force the user in any way we don't absolutely have to, and you're saying it's a bad idea to be insecure. Yes, it's a bad idea to be insecure, but it's not, and shouldn't be our call. > Also, we don't want to check the permissions too carefully, otherwise the one > crazy guy per 100 sysadmins is gonna complain that he can't run it as the user > named after his dog, in the group named after his budgie. Or something. But he can; ddclient'll just complain. (Unless the config file is not readable by $dog or members of $budgie.)
(In reply to comment #47) > Yes, it's a bad idea to be insecure, but it's not, and shouldn't be > our call. Having a password-containing file world-readable is absolutely ludicrous, and makes a mockery of the whole concept of security. The one guy in a million who actually thinks this is a good idea can *definitely* go patch the Perl script himself.
(In reply to comment #48) > (In reply to comment #47) > > Yes, it's a bad idea to be insecure, but it's not, and shouldn't be > > our call. > > Having a password-containing file world-readable is absolutely ludicrous. Let the user be ludicrous. The developer has done due diligence at install time. Anyway, how does having ddclient die if the file is world-readable make the file any less world-readable? It doesn't solve the problem, it just creates another one.
(In reply to comment #49) > It doesn't solve the problem, it just creates > another one. No, it alerts the sysadmin in a way he can't ignore, that he's made a (sackable or at least reprimandable) security mistake. It stays at *one* problem.
(In reply to comment #50) > (In reply to comment #49) > > It doesn't solve the problem, it just creates > > another one. > > No, it alerts the sysadmin in a way he can't ignore, that he's made a (sackable > or at least reprimandable) security mistake. It stays at *one* problem. I agree with Paul. We need to make a stand at some point of time. Though this is more in the domain of ddclient development that ddclient ebuild development. :) FYI, there is now a #gentoo-ddclient on irc.freenode.net as well.
(In reply to comment #51) > I agree with Paul. I spoke with seemant about it. He was "on the fence" but leaning toward leaving the upstream code as alone as possible. That means the program should break when the perms are wrong. Oh well. I'll get you next time, Gadget.
Created attachment 84511 [details] ddclient.initd This initscript tests and fails if ddclient.conf is world-readable. Just to be on the safe side.
Paul's patches apply cleanly and ddclient runs as expected (at least with my uber-simple setup).
Created attachment 88423 [details] ddclient-3.6.7.ebuild Made the "d" variable local.
The ebuild doesn't seem to work for me... looks like the patch would need a different path than what is currently being used? I get this output: >>> Emerging (1 of 1) net-dns/ddclient-3.6.7 to / >>> checking ebuild checksums ;-) >>> checking auxfile checksums ;-) >>> checking miscfile checksums ;-) >>> checking ddclient-3.6.7.tar.gz ;-) >>> Unpacking source... >>> Unpacking ddclient-3.6.7.tar.gz to /var/tmp/portage/ddclient-3.6.7/work * Applying ddclient-reasonable-security.patch ... * A dry-run of patch command succeeded, but actually * applying the patch failed! * Failed Patch: ddclient-reasonable-security.patch ! * ( /usr/local/portage/net-dns/ddclient/files/ddclient-reasonable-security.patch ) * * Include in your bugreport the contents of: * * /var/tmp/portage/ddclient-3.6.7/temp/ddclient-reasonable-security.patch-26803.out !!! ERROR: net-dns/ddclient-3.6.7 failed. Call stack: ebuild.sh, line 1539: Called dyn_unpack ebuild.sh, line 711: Called src_unpack ddclient-3.6.7.ebuild, line 27: Called epatch '/usr/local/portage/net-dns/ddclient/files/ddclient-reasonable-security.patch' eutils.eclass, line 337: Called die !!! Failed Patch: ddclient-reasonable-security.patch! !!! If you need support, post the topmost build error, and the call stack if relevant. --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/var/log/sandbox/sandbox-net-dns_-_ddclient-3.6.7-26802.log" rename: /usr/sbin/ddclient -------------------------------------------------------------------------------- Here is my emerge --info: Portage 2.1_rc4-r1 (default-linux/x86/2006.0, gcc-3.4.6, glibc-2.4-r3, 2.6.16-ck9 i686) ================================================================= System uname: 2.6.16-ck9 i686 Pentium III (Coppermine) Gentoo Base System version 1.12.0 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] dev-lang/python: 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r2 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r5 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium3 -O2 -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium3 -O2 -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://mirror.datapipe.net/gentoo ftp://ftp.ussg.iu.edu/pub/linux/gentoo ftp://gentoo.mirrors.tds.net/gentoo ftp://gentoo.chem.wisc.edu/gentoo/ http://ftp.club-internet.fr/pub/mirrors/gentoo" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="x86 apache2 apm berkdb bzip2 cgi ck-server cli dri eds esd extensions frxp ftp gdbm gif gstreamer imap isdnlog libwww mailbox maildir mmx mpm-prefork multiuser mysql nagios-dns nagios-ntp nagios-ping nagios-ssh ncurses no-old-linux nptl nptlonly ogg oss pam pcre pic pppd readline samba session snmp spamassassin spl ssl tcpd tools udev ups userlocales vhosts vorbis xml xorg zlib elibc_glibc kernel_linux userland_GNU" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, MAKEOPTS, PORTAGE_RSYNC_EXTRA_OPTS
Created attachment 88568 [details] Patch failure logfile
Created attachment 88577 [details, diff] ddclient-reasonable-security.patch It's caused by FEATURES="strict" (what a nasty gotcha). This modified patch works, after removing the paths from the first 2 lines.
Created attachment 89240 [details] ddclient-3.7.0.ebuild New release. Added "ssl" USE flag.
Created attachment 89242 [details] ddclient.initd Added "before cron" and "use dns logger", as in /etc/init.d/ntp-client
Created attachment 93921 [details] ddclient.initd (fixed) ddclient.initd (fixed) In the old initd script is there is an error: find: warning: you have specified the -maxdepth option after a non-option argument -name, but options are not positional (-maxdepth affects tests specified before it as well as those specified after it). Please specify options before other arguments. This new initd script fixed this!
Comment on attachment 89242 [details] ddclient.initd Yeah, findutils-4.3.0 has introduced that warning message.
Ok, ddclient 3.7.0 is working fine here. I think its ready for portage?
Hello! Is that normal, that SSL does not work? :( Can't locate IO/Socket/SSL.pm in @INC (@INC contains: /etc/perl /usr/lib/perl5/vendor_perl/5.8.8/i586-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.8 /usr/lib/perl5/vendor_perl /usr/lib/perl5/site_perl/5.8.8/i586-linux-thread-multi /usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_perl /usr/lib/perl5/5.8.8/i586-linux-thread-multi /usr/lib/perl5/5.8.8 /usr/local/lib/site_perl .) at /usr/sbin/ddclient line 1647. Portage 2.1.1_pre5-r3 (default-linux/x86/2006.0, gcc-4.1.1, glibc-2.4-r3, 2.6.17-gentoo-r5 i586) ================================================================= System uname: 2.6.17-gentoo-r5 i586 Geode(TM) Integrated Processor by AMD PCS Gentoo Base System version 1.12.4 Last Sync: Tue, 22 Aug 2006 00:20:01 +0000 ccache version 2.4 [enabled] app-admin/eselect-compiler: [Not Present] dev-lang/python: 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.4-r2 dev-util/confcache: 0.4.2-r1 sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.60 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.17 sys-devel/gcc-config: 1.3.13-r3 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i586-pc-linux-gnu" CFLAGS="-march=k6-2 -O3 -mmmx -m3dnow -pipe -fomit-frame-pointer -fno-align-functions -fno-align-loops -fno-align-jumps -fno-align-labels -mfpmath=387" CHOST="i586-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-march=k6-2 -O3 -mmmx -m3dnow -pipe -fomit-frame-pointer -fno-align-functions -fno-align-loops -fno-align-jumps -fno-align-labels -mfpmath=387 -fvisibility-inlines-hidden" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="" FEATURES="autoconfig ccache distlocks metadata-transfer parallel-fetch sandbox sfperms strict" GENTOO_MIRRORS="ftp://pandemonium.tiscali.de/pub/gentoo/" LANG="de_DE.utf8" LC_ALL="de_DE.utf8" LDFLAGS="-Wl,-O1 -Wl,-z,now -Wl,--sort-common" LINGUAS="de" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_EXTRA_OPTS="--exclude-from=/etc/portage/rsync_excludes" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local" SYNC="rsync://rsync.de.gentoo.org/gentoo-portage" USE="x86 3dnow a52 aac aalib acpi alsa apache2 bash-completion bzip2 cdinstall clamav crypt dbus dedicated dts dvd elibc_glibc fbcon ftp gd gif gpm hal iconv imap innodb input_devices_keyboard input_devices_mouse java javascript jpeg kernel_linux linguas_de mmx mp3 mpeg mysql mysqli ncurses nls nptl odbc ogg pam pcre php png quicktime readline samba sdl session skey slang spell ssl symlink szip tcpd threads tiff truetype unicode upnp usb userland_GNU v4l vcd vhosts video_cards_fbdev video_cards_nsc video_cards_v4l video_cards_vesa video_cards_vga vorbis wifi win32codecs xml xvid zlib" Unset: CTARGET, INSTALL_MASK
Ok! Forget it ;) emerge IO-Socket-SSL fixed it!
Created attachment 95055 [details] ddclient.initd Wrapped the find command in quotes.
Created attachment 95056 [details] ddclient-3.7.0.ebuild Removed the "ssl" USE flag, making it mandatory, because ddclient falls over inelegantly if asked to use ssl when its deps are missing. Reminder: The easy installation commands for this ebuild are at: http://forums.gentoo.org/viewtopic-p-3236622.html#3236622
*** Bug 146172 has been marked as a duplicate of this bug. ***
It's in portage finally! Thanks everyone!
