On Tuesday 02 October 2018 14:15:25 Austin S. Hemmelgarn wrote: > On 2018-10-02 13:29, Gene Heskett wrote: > > On Tuesday 02 October 2018 12:34:40 Ashwin Krishna wrote: > >> Hi All, > >> > >> We propose to have the call on Oct 8th at 11 AM Mountain Time. > >> > >> Agenda: > >> * Zmanda's Acquisition by BETSOL > >> * Attendee Introductions > >> * Existing Governance Model of Amanda Community > >> * Suggested changes to the Governance Model > >> * BETSOL's Commitment to Open Source Community > >> > >> We have taken a note of all the suggestions received on the mailing > >> list and we will go through the same on the call. > >> > >> Meeting Details: > >> Amanda Open Source Community Discussion > >> Mon, Oct 8, 2018 11:00 AM - 12:00 PM MDT > >> Please join my meeting from your computer, tablet or smartphone. > >> https://global.gotomeeting.com/join/438069045 > >> You can also dial in using your phone. > >> United States: +1 (786) 535-3211 > >> Access Code: 438-069-045 > >> First GoToMeeting? Let's do a quick system check: > >> https://link.gotomeeting.com/system-check > >> > >> Regards, > >> Ashwin Krishna > >> > >> -----Original Message----- > >> From: Nathan Stratton Treadway <[email protected]> > >> Sent: Thursday, September 27, 2018 9:01 PM > >> To: Ashwin Krishna <[email protected]> > >> Cc: [email protected] > >> Subject: Re: Zmanda acquired from Carbonite by BETSOL -- future of > >> Amanda development? > >> > >> Ashwin, thanks very much for getting in contact with the Amanda > >> mailing list. > >> > >> On Thu, Sep 27, 2018 at 06:16:02 +0000, Ashwin Krishna wrote: > >>> We are 100% committed to the open source community and will be > >>> contributing to the code base to the best of our abilities. > >> > >> [...] > >> > >>> I want to assure you that we are actively investing in growing > >>> Amanda and we have young enthusiastic engineers in the team. > >>> > >>> You can expect the next Amanda releases to include support for > >>> newer versions of operating systems, defect fixes, security > >>> enhancements etc. > >> > >> [...] > >> > >>> We have retained the team members that we could of previous Zmanda > >>> team. I can tell you that it's not easy without support from the > >>> community members. We encourage the community members to guide and > >>> contribute as much as you can. If you need commit access to the > >>> code base, please don't hesitate to reach out to us. You can > >>> expect our commitment and support to you. > >> > >> On Thu, Sep 27, 2018 at 22:54:02 +0000, Ashwin Krishna wrote: > >>> We are planning to host a conference call and would like all the > >>> active admins and community members to join to have a discussion > >>> with the Zmanda team at BETSOL regarding future collaborations. > >>> > >>> Will be sending out the meeting details (US time) with the agenda > >>> later. > >> > >> It sounds like getting the new BETSOL team in direct contact with > >> the admins for the mailing list and other amanda.org-related > >> resources in an important step at this point. > >> > >> > >> However, I would say that for many of us here on the list, the most > >> notable change in the past 7 months is not related those things > >> (which have continued to chug along as before), but rather the lack > >> of "a developer" to move things along here on the public lists and > >> in the public source repo. > >> > >> A decade or two ago it sounds like there were a number of > >> developers involved, but more recently it's just been one or two > >> Zmanda people who have served that role. > >> > >> Obviously this could be a good time to reconsider this arrangement > >> if there are in fact other people ready to jump in, but off hand > >> I'm guessing that what's likely to work going forward is for there > >> to be a small number of BETSOL developers back in that role. > >> > >> As an Amanda user who has tried to contribute back a few > >> improvements to the code line, I'm not really looking to have > >> direct commit access myself, but rather hope to get back to someone > >> (hanging out here on the mailing lists) who can take the patches I > >> came up with hacking around on my own system and understand whether > >> or not they will really work for everyone, and who will know which > >> branches should have that change pushed onto them, and what tweaks > >> are needed to make the patch apply to some older branch, etc. > >> > >> So, here's hoping you all at BETSOL are soon able to identify > >> someone/a few people to take over that function, and patches and > >> discussions can start flowing again.... > >> > >> Nathan > >> > >> p.s. Personally I'd say that, rather than than a new major release > >> with support for newer versions of operating systems and whatnot., > >> more urgent would be a minor release to gather up the handful of > >> bugfixes which have already been discussed since 3.5.1 came out and > >> get them published as part of an official release.... > > > > +10, the 3.3.7p1 planner in particular is in serious need of help. > > It refuses to adjust the schedule of the 3 largest members of my > > disklist, choosing instead to do all three level 0's on the same > > run, so a 30 gig average backup, has become 24 gigs for many nights, > > followed by a 60+ gig run using 3 vtapes. 5 or 6 tapelist cycles in > > a row now. I'd build this mythical 3.5.1 but its been hidden > > someplace my browsing has not found. > > You should be able to get 3.5.1 here: > https://sourceforge.net/projects/amanda/files/amanda%20-%20stable/3.5. >1/ > > That said, 3.5.1 doesn't seem to be much better based on my > experience. I've got a backup set at work handling about 600GB of data > with about four of the 132 DLE's accounting for roughly 20% of the > total size, and the only way I've found to keep Amanda (regardless of > versions I've tested) from running level zero backups for all four of > those DLE's at the same time and taking far too long to push them out > to S3 is to manually track the dump cycles and force run each of them > on a separate day within about 5 dumps of when they would all be up > again, which is obviously not a reasonable solution (part of the point > of using Amanda in the first place is so we don't have to babysit the > backup system).
I agree, got it, built and installed it, now have a string of this as return from an amcheck: ERROR: coyote: selfcheck request failed: file/dir '/usr/local/etc' (/usr/local/etc/amanda-security.conf) is writable by the group ERROR: shop: selfcheck request failed: file/dir '/usr/local/etc' (/usr/local/etc/amanda-security.conf) is writable by the group ERROR: lathe: selfcheck request failed: file/dir '/usr/local/etc' (/usr/local/etc/amanda-security.conf) is writable by the group ERROR: GO704: selfcheck request failed: file/dir '/usr/local/etc' (/usr/local/etc/amanda-security.conf) is writable by the group ERROR: picnc: selfcheck request failed: file/dir '/usr/local/etc' (/usr/local/etc/amanda-security.conf) is writable by the group Client check: 5 hosts checked in 11.356 seconds. 5 problems found. owner:group is as shown in the man page, with perms=-rw-r--r--. owner:group is amanda:disk except that file is root:root A puzzle I need to solve by around 1:30 in the morning when the real run starts. Or shut down my backups. The man page says its to be in /etc/amanda, but since this is a local build, its in /usr/local/etc/amanda. -- Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene>
