Server issues?

[Daniel J. Luke]

On Sep 8, 2017, at 12:32 PM, Ryan Schmidt <ryandesign at macports.org> wrote:
> On Sep 8, 2017, at 11:08, Daniel J. Luke wrote:
>> On Sep 8, 2017, at 11:55 AM, Ryan Schmidt wrote:
>>> On Sep 8, 2017, at 10:51, Daniel J. Luke wrote:
>>>> On Sep 7, 2017, at 9:37 AM, Ryan Schmidt wrote:
>>>>> That'll happen when a huge port gets built and the resulting packages must be transferred between my private rsync server and the public one. In this case, it was probably that clang-devel, llvm-devel, and lldb-devel were updated, and this produced many large binaries (six 900MB binaries for clang-devel; seven 750MB binaries for llvm-devel; two 275MB binaries for lldb-devel).
>>>>> 
>>>>> I do intend to increase the speed of the internet connection soon so that this will be less of a problem.
>>>> 
>>>> Would it be reasonable to move things around so we're not dependent on your (presumably consumer-class) internet connection?
>>> 
>>> What would you suggest move, where?
>> 
>> I don't know how the current infrastructure is set up - so I can't make concrete suggestions.
>> 
>> MacPorts is used pretty widely - I would be surprised if there was no one at an ISP or University who could offer us some space/power/bandwidth. [I may be able to help find some place like that, if it were desired].
> 
> We asked all of our existing mirror providers last year and were not able to find such an arrangement. What we found was that Friedrich-Alexander-Universität was willing to become our master public rsync server and the origin server for distfiles and packages that feeds our CDN. So that is the arrangement we currently have, with them pulling the files from my private rsync server every half hour. The problem arises when several gigabytes of new files have been created in a short time, since the current rsync run must complete before a new one will start.

One solution might be to separate the build/distfile mirroring from the portfile mirroring. You could probably even do that by running separate rsync's for those on your home connection and doing some QoS setup to depref the build uploads (so they wouldn't block portfile updates).

>>> Last I looked into moving the Xserves to a data center, colocation was extremely expensive.
>> 
>> MacStadium seems to have pretty reasonable pricing (mini with gigE for $54/month), but again I don't know what our infrastructure requires.
> 
> The buildbot setup currently consists of four Xserves and a Power Mac G5.

so ~ 1/4 cabinet?

>>> My Internet connection is not consumer-class. If it were a consumer connection, it would be much faster and much cheaper, but ISPs does not allow running servers on consumer connections, so it is an expensive and slow business-class connection.
>> 
>> If we don't care about having static IP addresses for these machines, I have a 2 post rack in my basement that's mostly empty and a 1gig consumer connection that I'd be happy to share with the project.
> 
> Does your consumer Internet connection allow running a publicly-accessible server

yes, although running something like this would maybe require upgrading to a 'business' account (which they don't publish pricing for). I can ask.

> We do currently have a single static IP with ports 80, 443, and 873 open for the buildbot web site and the rsync server. Although it is not entirely working at the moment, the server is also supposed to be sending emails on failed builds; my understanding is that sending mail from a dynamic address makes other servers more likely to classify the message as spam.

it shouldn't if it's set up correctly (ie. to relay through a smarthost).
-- 
Daniel J. Luke