Re: 3.1.2 : Problems with mails?
quote who=Dustin J. Mitchell dunno about getting it hosted at overlay-servers, I have to research that ... Lisa, do you have any pointers on that front? Hi Dustin, Unfortunately it's been some time sine I was a Gentoo dev and when I was active overlays were only just coming about. I'm sorry that I'm not able to give any pointers here beyond what might be on gentoo.org. -- Regards, -Lisa http://www.crudvision.com
Re: Nitpicks? -- permissions
quote who=Dustin J. Mitchell On Sat, Sep 11, 2010 at 10:42 PM, Lisa Seelye l...@thedoh.com wrote: Disk permissions and file permissions are always a nightmare. Some things aren't right and amcheck complains about each one in turn. It would be useful to have some kind of thorough lint mode, perhaps with a --fix-permissions to repair the permissions (when run with root). Ideally amcheck would be finding all of the permissions problems on the first run - although sometimes one permission problem can make it impossible to find the next. Is there some specific condition that you're seeing appear only on the second run? As for adding a --fix-permissions option is an interesting idea, but I worry that it would blindly 'mkdir' and 'chown' and 'chmod' things that you might not want it to. Note that many missing directories are created at first run. If some of those are missing, we could fix that up. Do you have a particular example you'd like me to look at? When I first configured Amanda on my Gentoo servers some time ago I ran into the problem where several installed files were not correctly owned or had improper permissions. I would correct one, perhaps in /var/spool/amanda and re-run amcheck and another fault would come up. While this may be the fault of the .ebuild author having not correctly set the permissions my memory is that configuring the permissions and ownerships correctly was a big pain. An included tool to check all required files/directories in one pass (instead of bailing at the first error) would be very useful. -- Regards, -Lisa http://www.crudvision.com
Re: Nitpicks? -- permissions
quote who=Dustin J. Mitchell I bet most of you have some small nitpick with Amanda that you've never felt warranted an email. Well, now's your chance! I'd like to put some polish on Amanda, and it's hard for me to see the areas that need burnishing, since I work on Amanda all day, every day. - typo in a manpage? - command-line usage oddity? - confusing use of terminology? - something else? Start up a new thread on the mailing list, or email me privately if you'd prefer, to let me know what's bugging you. Bonus points for also supplying a patch, but that's not at all required! Note that I do reserve the right to say, actually, that's complicated (and explain why). Dustin Disk permissions and file permissions are always a nightmare. Some things aren't right and amcheck complains about each one in turn. It would be useful to have some kind of thorough lint mode, perhaps with a --fix-permissions to repair the permissions (when run with root). This one is for 2.6 series, I don't know if it's been addressed in a later version. -- Regards, -Lisa http://www.crudvision.com
Re: sudden failure of backups and amcheck
quote who=John Blinka Clearly something has broken on my system. I have not changed anything directly related to amanda, so I suspect that a change in something it depends on has broken things. According to some gentoo utilities, amanda depends on glib at runtime, glib was upgraded at the time of the backup failures, and g_thread_supported() appears to be a glib function. Any advice on how to proceed from here? Thanks for your help! Hi John, I ran into this recently as well. Try: emerge =dev-libs/glib-2.22.5 emerge amanda You may want to add an entry to /etc/portage/package.mask for dev-libs/glib-2.22.5. Note that Amanda (at least the 2.6 series) has issues with glib versions higher than 2.22. -- Regards, -Lisa http://www.crudvision.com
Re: Amanda 2.6.0p2 + S3 results in cURL errors
quote who=Dustin J. Mitchell On Wed, Sep 10, 2008 at 4:10 PM, Lisa Seelye [EMAIL PROTECTED] wrote: While listing S3 keys: CURL error: Failed writing body (CURLcode 23) taper: Error writing label BUCKETNAME012 to device BUCKETNAME012/. First, I would recommend using a single bucket for all of your Amanda backups, with device names such as s3:BUCKETNAME/tape012 since Amazon limits you to 100 buckets. I'll move to that convention after this bug is resolved. CURLE_WRITE_ERROR (23) An error occurred when writing received data to a local file, or an error was returned to libcurl from a write callback. My best guess is that Amazon is returning more data than Amanda expects. Can you add device_property VERBOSE YES to your amanda.conf and re-run to see what additional information appears in the logs? I'll add this configuration directive and have the log data or the next time the error comes up. Dustin -- Storage Software Engineer http://www.zmanda.com !DSPAM:48c92b75117151708128526! -- Regards, -Lisa http://www.crudvision.com
