Thread: PgFoundry Move
Hello, In the essence of being efficient I would like to suggest that we move Pgfoundry. I know we have been trying to "migrate" for what seems like forever but maybe it is time we just up and move the whole site :). I would like to again offer Command Prompt's services in hosting pgFoundry. Some key benefits to moving the system to CMD: 1. You can call us 2. You can call us at 3:00 am 3. We have service level monitoring 4. We have a lot of bandwidth 5. All our stuff is on natural gas conditioned power generators We have proven to be very stable with the Buildfarm and with the archives. With the only recent problem with either not being at the hands of CMD, (gentle poke at Andrew). The longest outage we have had in the last 24 months is four hours for a single machine that we had to recover from backup. The longest outage we have had that was global in the last 24 months (that wasn't scheduled) was 90 minutes when we lost a nic in one of our firewalls. We did recently have a scheduled outage of 4.5 hours but that was from midnight to 4:30 while we upgraded some power facilities. The only change that we would require would be to move the system to Linux. This should be a very minor change in general and will probably require very if any work on the Gforge end. Thoughts, Flames, better suggestions? Sincerely, Joshua D. Drake -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: PLphp, PLperl - http://www.commandprompt.com/
Not sure where this email came from, but JoshB has gone to the trouble of setting up a new server for pgFoundry, and when that is ready, it will be moved there ... Is there a problem that I haven't been informed of with the server it is currently running on? On Mon, 16 Jan 2006, Joshua D. Drake wrote: > Hello, > > In the essence of being efficient I would like to suggest that we move > Pgfoundry. I know we have been trying to "migrate" for what seems like > forever but maybe it is time we just up and move the whole site :). > > I would like to again offer Command Prompt's services in hosting > pgFoundry. > > Some key benefits to moving the system to CMD: > > 1. You can call us > 2. You can call us at 3:00 am > 3. We have service level monitoring > 4. We have a lot of bandwidth > 5. All our stuff is on natural gas conditioned power generators > > We have proven to be very stable with the Buildfarm and with the archives. > With the only recent problem with either not being at the hands of CMD, > (gentle poke at Andrew). > > The longest outage we have had in the last 24 months is four hours for a > single > machine that we had to recover from backup. > > The longest outage we have had that was global in the last 24 months (that > wasn't > scheduled) was 90 minutes when we lost a nic in one of our firewalls. > > We did recently have a scheduled outage of 4.5 hours but that was from > midnight > to 4:30 while we upgraded some power facilities. > > The only change that we would require would be to move the system to Linux. > This should be a very minor change in general and will probably require > very if any work on the Gforge end. > > Thoughts, Flames, better suggestions? > > Sincerely, > > Joshua D. Drake > > -- > The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 > PostgreSQL Replication, Consulting, Custom Development, 24x7 support > Managed Services, Shared and Dedicated Hosting > Co-Authors: PLphp, PLperl - http://www.commandprompt.com/ > > > ---------------------------(end of broadcast)--------------------------- > TIP 9: In versions below 8.0, the planner will ignore your desire to > choose an index scan if your joining column's datatypes do not > match > ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Well, the problems with the current setup are well known, including: - running on a machine that is sometimes rather loaded - no separation of users / gforge , meaning we have had to restrict what users / groups can do for security reasons - unsupported (and in fact unknown) mailman version - missing features like SVN support JoshB and others have been working on a new box, that's true. But it's been a very long time coming. Joshua's offer is attractive because of the level of support promised. I can certainly testify that when I screwed up the buildfarm badly, CP was wonderfully responsive and we were back running with almost no data loss within a couple of hours. Service like that is hard to beat. cheers andrew On Mon, 2006-01-16 at 14:59 -0400, Marc G. Fournier wrote: > Not sure where this email came from, but JoshB has gone to the trouble of > setting up a new server for pgFoundry, and when that is ready, it will be > moved there ... > > Is there a problem that I haven't been informed of with the server it is > currently running on? > > > On Mon, 16 Jan 2006, Joshua D. Drake wrote: > > > Hello, > > > > In the essence of being efficient I would like to suggest that we move > > Pgfoundry. I know we have been trying to "migrate" for what seems like > > forever but maybe it is time we just up and move the whole site :). > > > > I would like to again offer Command Prompt's services in hosting > > pgFoundry. > > > > Some key benefits to moving the system to CMD: > > > > 1. You can call us > > 2. You can call us at 3:00 am > > 3. We have service level monitoring > > 4. We have a lot of bandwidth > > 5. All our stuff is on natural gas conditioned power generators > > > > We have proven to be very stable with the Buildfarm and with the archives. > > With the only recent problem with either not being at the hands of CMD, > > (gentle poke at Andrew). > > > > The longest outage we have had in the last 24 months is four hours for a > > single > > machine that we had to recover from backup. > > > > The longest outage we have had that was global in the last 24 months (that > > wasn't > > scheduled) was 90 minutes when we lost a nic in one of our firewalls. > > > > We did recently have a scheduled outage of 4.5 hours but that was from > > midnight > > to 4:30 while we upgraded some power facilities. > > > > The only change that we would require would be to move the system to Linux. > > This should be a very minor change in general and will probably require > > very if any work on the Gforge end. > > > > Thoughts, Flames, better suggestions? > > > > Sincerely, > > > > Joshua D. Drake > > > > -- > > The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 > > PostgreSQL Replication, Consulting, Custom Development, 24x7 support > > Managed Services, Shared and Dedicated Hosting > > Co-Authors: PLphp, PLperl - http://www.commandprompt.com/ > > > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 9: In versions below 8.0, the planner will ignore your desire to > > choose an index scan if your joining column's datatypes do not > > match > > > > ---- > Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) > Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 > _______________________________________________ > Gforge-admins mailing list > Gforge-admins@pgfoundry.org > http://pgfoundry.org/mailman/listinfo/gforge-admins
On Mon, 16 Jan 2006, Andrew Dunstan wrote: > > Well, the problems with the current setup are well known, including: > - running on a machine that is sometimes rather loaded Ya, and if the new server isn't up / running by end of Feb, we can move this over to the new 64bit server that I've got here in the shop being configured ... > - no separation of users / gforge , meaning we have had to restrict what > users / groups can do for security reasons The only reason for that is because of the move to the new server ... if you guys want a users.pgfoundry.org vServer setup, I can do that in <10 minutes ... > - unsupported (and in fact unknown) mailman version Wasn't Joshua planning on fixing that? > - missing features like SVN support SVN support is there, and last I heard on that, Joshua was reading through the docs on how to setup that ... > JoshB and others have been working on a new box, that's true. But it's > been a very long time coming. That it has ... and the solution to that constantly seems to be "lets bring someone else new onto the admin team since they apparently have spare time" ... if JoshuaD has the spare time to set this up on one of his Linux boxes (which isn't acceptable, the reason I agreed to move pgfoundry in the first place was that the box it moved to was running FreeBSD to match the rest of our *core* servers, including wwwmaster), then how come, in almost 12 months, he hasn't had the time to do the same getting it up and running on a server that was bought specifically for that purpose? It isn't lack of access, since everyone involved with that side project has root access to do what is required ... The problem isn't moving the vServer ... the problem is that JoshB wants to move the vServer *and* upgrade pgfoundry at the same time ... if it was a matter of just moving the vServer, that could have been done simply enough 12 months ago with a simple rsync, same as we did when we moved wwwmaster to another server ... Personally, I'm in no rush to move it, so whenever JoshB is ready with the new server, we'll move it ... until then, I'll keep upgrading the hardware and moving pgFoundry up onto more powerful machines ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Mon, Jan 16, 2006 at 02:59:29PM -0400, Marc G. Fournier wrote: > > Not sure where this email came from, but JoshB has gone to the > trouble of setting up a new server for pgFoundry, and when that is > ready, it will be moved there ... > > Is there a problem that I haven't been informed of with the server > it is currently running on? There are several problems, but I'll stick to the systemic one that such a move can address. Right now, there is exactly one very hard-working person, Sean Chittenden, who can put his hands on the hardware when needed. This is a fragile situation, and it's already cost months of effort because Sean can't put the pgFoundry machine's welfare ahead of everything else in his life. Command Prompt has people on call 24/7, and Josh Drake has mentioned to me that their absolute worst situation so far resulted in four hours of downtime. Cheers, D -- David Fetter david@fetter.org http://fetter.org/ phone: +1 415 235 3778 Remember to vote!
<snip the parts that I won't comment on at this time, which are the actual points of your mail I guess :P> > We did recently have a scheduled outage of 4.5 hours but that > was from midnight to 4:30 while we upgraded some power facilities. You do realise that's the middle of the working day, right? :P I'm not saying that it's bad, it's definitly not. I'm just saying that "middle of the night" really doesn't exist in this kind of operations. Something that should always be considered. //Magnus
>> - unsupported (and in fact unknown) mailman version > > Wasn't Joshua planning on fixing that? For the migration yes. I haven't touched the current machine as it is production. > >> - missing features like SVN support > > SVN support is there, and last I heard on that, Joshua was reading > through the docs on how to setup that ... I did setup and install SVN but I did not getting it working "with" gforge and as I stated in an email I would leave that to someone more knowledgeable about gforge itself. > That it has ... and the solution to that constantly seems to be "lets > bring someone else new onto the admin team since they apparently have > spare time" ... if JoshuaD has the spare time to set this up on one of > his Linux boxes Well first a good portion of this isn't "spare time". It is that I have resources in the management and infrastructure area regardless of myself. It is the same reason we are about to host the search. > (which isn't acceptable, the reason I agreed to move pgfoundry in the > first place was that the box it moved to was running FreeBSD to match > the rest of our *core* servers, including wwwmaster) There is no reason except technical bias to keep it on FreeBSD and a lot of reasons (including a larger support pool) to put it on Linux. > , then how come, in almost 12 months, he hasn't had the time to do the > same getting it up and running on a server that was bought > specifically for that purpose? It isn't lack of access, since everyone > involved with that side project has root access to do what is required > ... We are also talking about physical access. > > The problem isn't moving the vServer ... the problem is that JoshB > wants to move the vServer *and* upgrade pgfoundry at the same time ... > if it was a matter of just moving the vServer, that could have been > done simply enough 12 months ago with a simple rsync, same as we did > when we moved wwwmaster to another server ... We aren't really talking about JoshB's efforts as much as trying to get PgFoundry moved in general. Sincerely, Joshua D. Drake -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: PLphp, PLperl - http://www.commandprompt.com/
> You do realise that's the middle of the working day, right? :P > > I'm not saying that it's bad, it's definitly not. I'm just saying that > "middle of the night" really doesn't exist in this kind of operations. > Something that should always be considered. > The real point is that it was scheduled ;) Joshua D. Drake > > //Magnus > -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: PLphp, PLperl - http://www.commandprompt.com/
On Mon, 16 Jan 2006, David Fetter wrote: > On Mon, Jan 16, 2006 at 02:59:29PM -0400, Marc G. Fournier wrote: >> >> Not sure where this email came from, but JoshB has gone to the >> trouble of setting up a new server for pgFoundry, and when that is >> ready, it will be moved there ... >> >> Is there a problem that I haven't been informed of with the server >> it is currently running on? > > There are several problems, but I'll stick to the systemic one that > such a move can address. Right now, there is exactly one very > hard-working person, Sean Chittenden, who can put his hands on the > hardware when needed. This is a fragile situation, and it's already > cost months of effort because Sean can't put the pgFoundry machine's > welfare ahead of everything else in his life. > > Command Prompt has people on call 24/7, and Josh Drake has mentioned > to me that their absolute worst situation so far resulted in four > hours of downtime. If its a matter of time on Sean's part, can we ship the server up to Joshua to put onto their network? My one criteria in all of this, from day one, was that it had to be FreeBSD based, it has to be redundant with our current *core* infrastructure ... as JoshB has stated in the past, he's sunk personal money into the server *for* pgFoundry, so just 'ditching' that server, IMHO, seems to be a no-op ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
> > If its a matter of time on Sean's part, can we ship the server up to > Joshua to put onto their network? > > My one criteria in all of this, from day one, was that it had to be > FreeBSD based, it has to be redundant with our current *core* > infrastructure ... as JoshB has stated in the past, he's sunk personal > money into the server *for* pgFoundry, so just 'ditching' that server, > IMHO, seems to be a no-op ... Well that machine is also doing other things that are sponsored, such as Bizgres so I am not sure that would be an issue. Sincerely, Joshua D. Drake > > ---- > Marc G. Fournier Hub.Org Networking Services > (http://www.hub.org) > Email: scrappy@hub.org Yahoo!: yscrappy ICQ: > 7615664 -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: PLphp, PLperl - http://www.commandprompt.com/
Actually, I would like to put my hands for help.
I do work as a sysadmin for lastminute.com and mainly as the pgsql dba in the house, leading battles against informix, sql server, and oracle ones. (a team of 6)
I've been reading this mailing lists (admin/www/novice/hackers/others) for a while (> 1 year now, for sure). I've made myself reading books, I'd never went to a proper college and I play with linux since 1997. I've also worked for the third ISP in my country for 4 years, as a perl programer.
I am from Argentina, but I live in the Uk. I do work on-call the whole year for lastminute.com, but I can also give a couple of hours per day for this project.
PostgreSQL gave me a job, why in hell I shouldn't help the ones who actually done this? I am not a *nix king, but a whitehat and fast growing boy.
Let me know your thoughts, mines are to help and grow.
(28 years old, single, etc,etc,etc,etc. Beer, pizza, marlboro)
Best regards,
Guido.
On 1/16/06, Magnus Hagander <mha@sollentuna.net> wrote:
<snip the parts that I won't comment on at this time, which are the
actual points of your mail I guess :P>
> We did recently have a scheduled outage of 4.5 hours but that
> was from midnight to 4:30 while we upgraded some power facilities.
You do realise that's the middle of the working day, right? :P
I'm not saying that it's bad, it's definitly not. I'm just saying that
"middle of the night" really doesn't exist in this kind of operations.
Something that should always be considered.
//Magnus
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
--
/"\ ASCII Ribbon Campaign .
\ / - NO HTML/RTF in e-mail .
X - NO Word docs in e-mail .
/ \ -----------------------------------------------------------------
> My one criteria in all of this, from day one, was that it had > to be FreeBSD based, it has to be redundant with our current > *core* infrastructure ... While this is a very good point, I don't think it should be overstressed. Yes, it's very good to have that type of redundancy. But if it can be built on a different level than the OS, that would be even better. And it *is* a bit of a problem that there are a lot less ppl skilled in FreeBSD. I know personally of several cases where things have been notably delayed because nobody around really *knew* FreeBSD, specifically with jails, good enough. Yes, a lot of things are the same because it's still *nix. And for critical stuff, I know we can page you. And usually, I assume that results in quick action (don't think I've ever had to, really). But at least I don't want to wake you up in the middle of the night for something that's not that urgent. Now, I'm not saying we should necessariliy change anything. I am just saying that this difference in "available knowledge" is something that whould be weighed into discussions like these. //Magnus
On Monday 16 January 2006 15:33, Marc G. Fournier wrote:
> On Mon, 16 Jan 2006, David Fetter wrote:
> > On Mon, Jan 16, 2006 at 02:59:29PM -0400, Marc G. Fournier wrote:
> >> Not sure where this email came from, but JoshB has gone to the
> >> trouble of setting up a new server for pgFoundry, and when that is
> >> ready, it will be moved there ...
> >>
> >> Is there a problem that I haven't been informed of with the server
> >> it is currently running on?
> >
> > There are several problems, but I'll stick to the systemic one that
> > such a move can address. Right now, there is exactly one very
> > hard-working person, Sean Chittenden, who can put his hands on the
> > hardware when needed. This is a fragile situation, and it's already
> > cost months of effort because Sean can't put the pgFoundry machine's
> > welfare ahead of everything else in his life.
> >
> > Command Prompt has people on call 24/7, and Josh Drake has mentioned
> > to me that their absolute worst situation so far resulted in four
> > hours of downtime.
>
> If its a matter of time on Sean's part, can we ship the server up to
> Joshua to put onto their network?
>
> My one criteria in all of this, from day one, was that it had to be
> FreeBSD based, it has to be redundant with our current *core*
> infrastructure ... as JoshB has stated in the past, he's sunk personal
> money into the server *for* pgFoundry, so just 'ditching' that server,
> IMHO, seems to be a no-op ...
>
based on my interaction with the foundry admins, afaict the single thing
stopping us from getting pgfoundry onto a new server is that we're trying to
do it on bsd (reread fetters' email for a good synopisis of this). At what
point do we decide moving forward is more important than the os we are
putting it on?
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
On Mon, 16 Jan 2006, Robert Treat wrote: > based on my interaction with the foundry admins, afaict the single thing > stopping us from getting pgfoundry onto a new server is that we're > trying to do it on bsd (reread fetters' email for a good synopisis of > this). At what point do we decide moving forward is more important than > the os we are putting it on? Never, cause the longer it takes to move it, the less requirement there is to move it as I bring on better/more powerful servers *shrug* Within the next month or so, we'll have a new 64bit server going online, which I'll be able to move pgfoundry over to that has faster drives and more memory *shrug* ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Monday 16 January 2006 10:26, Joshua D. Drake wrote: > Hello, > > In the essence of being efficient I would like to suggest that we move > Pgfoundry. I know we have been trying to "migrate" for what seems like > forever but maybe it is time we just up and move the whole site :). > > I would like to again offer Command Prompt's services in hosting > pgFoundry. > > Some key benefits to moving the system to CMD: > > 1. You can call us > 2. You can call us at 3:00 am > 3. We have service level monitoring > 4. We have a lot of bandwidth > 5. All our stuff is on natural gas conditioned power generators > > We have proven to be very stable with the Buildfarm and with the archives. > With the only recent problem with either not being at the hands of CMD, > (gentle poke at Andrew). > > The longest outage we have had in the last 24 months is four hours for a > single > machine that we had to recover from backup. > > The longest outage we have had that was global in the last 24 months > (that wasn't > scheduled) was 90 minutes when we lost a nic in one of our firewalls. > > We did recently have a scheduled outage of 4.5 hours but that was from > midnight > to 4:30 while we upgraded some power facilities. > > The only change that we would require would be to move the system to Linux. > This should be a very minor change in general and will probably require > very if any work on the Gforge end. > > Thoughts, Flames, better suggestions? I'll weigh in on this because like Marc I'm a FreeBSD guy. From my understanding the FreeBSD requirement is there to allow for ubiquitist role sharing. ie it's just a mater of moving (rsyncing) the VM from one box to another and away we go. FreeBSD happens to be handy for this currently because that is what the rest of the pg cluster boxen run. Beyond that I can not see a technical reason that requires FreeBSD. My concerns with a plan like this are: A) I do not know linux as well as FreeBSD. B) Can infrastructure be provided to allow for timely disaster recovery in the event of JD's hosting falling off the face of the earth, (much the same way the pg servers in panama fell off a while ago). C) How do we settle on the distro/version of the month, this fundamental issue within Linux has always left me with a bad taste in my mouth. (this is a personal item and has nothing to say for the quality of FreeBSD or Linux/distro). D) How does doing something like this affect -core in general (I'm not part of core so i have no idea) Other than those I'll take the standard Canadian fence sitting stance.... > > Sincerely, > > Joshua D. Drake -- Darcy Buskermolen Wavefire Technologies Corp. http://www.wavefire.com ph: 250.717.0200 fx: 250.763.1759
On Monday 16 January 2006 13:38, Marc G. Fournier wrote: > On Mon, 16 Jan 2006, Stefan Kaltenbrunner wrote: > > Well - when Darcy and I upgraded the box to FreeBSD6 a week ago or so it > > didn't came back up. according to sean the reason for that is/was a bad > > disk or a b0rked motherboard - before we put that box into (more > > serious) production we should fix that problem... > > 'k, stupid question but, if one drive took it down, then why isn't it > running any sort of RAID? :( It's running geom based mirroring. (g_mirror) > > ---- > Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) > Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 > _______________________________________________ > Gforge-admins mailing list > Gforge-admins@pgfoundry.org > http://pgfoundry.org/mailman/listinfo/gforge-admins -- Darcy Buskermolen Wavefire Technologies Corp. http://www.wavefire.com ph: 250.717.0200 fx: 250.763.1759
> My concerns with a plan like this are: > A) I do not know linux as well as FreeBSD. 80% of the Gforge admins are Linux guys afaik, which is why we need more FreeBSD help. > B) Can infrastructure be provided to allow for timely disaster > recovery in the > event of JD's hosting falling off the face of the earth, (much the > same way > the pg servers in panama fell off a while ago). We don't have this *really* in the case of most of the infrastructure, and this isn't in place for pgFoundry right now with Marc hosting, afaik. It is an issue we should be concerned with regardless of who's hosting. That and backup. I've tried to address what's happening (or not happening as I'm afraid) with backup before. > C) How do we settle on the distro/version of the month, this > fundamental issue > within Linux has always left me with a bad taste in my mouth. (this > is a > personal item and has nothing to say for the quality of FreeBSD or > Linux/distro). Unlike *BSD? Generally there have been distros like Debian and Slackware that have been server grade for over 10 years and are solid. I think the distro of the month is a unwarranted slam from FreeBSD people who don't see that others see BSD the same way (Free, Net, Open, etc) just with less choice for their respective communities. There are lots of Linux distros. Some are better at the desktop, some are better at the server. Coming up with a consensus of what to use would be pretty easy to do. That being said, I don't foresee a day that we'd use Linux just because everything else is running on FreeBSD. Being consistent is a good thing. > D) How does doing something like this affect -core in general (I'm > not part of > core so i have no idea) > I don't think it general does. PgFoundry is isolated away from -core. Regards, Gavin
Gavin M. Roy wrote: >> My concerns with a plan like this are: >> A) I do not know linux as well as FreeBSD. > > 80% of the Gforge admins are Linux guys afaik, which is why we need > more FreeBSD help. Correct but the pool of Linux helpers is getting larger by the day. FreeBSD isn't, at least not at nearly the same rate. > > >> B) Can infrastructure be provided to allow for timely disaster >> recovery in the >> event of JD's hosting falling off the face of the earth, (much the >> same way >> the pg servers in panama fell off a while ago). > > We don't have this *really* in the case of most of the infrastructure, We do have this with CMD though. > and this isn't in place for pgFoundry right now with Marc hosting, > afaik. It is an issue we should be concerned with regardless of who's > hosting. That and backup. I've tried to address what's happening (or > not happening as I'm afraid) with backup before. We would back up this machine a minimum of once a day and could do it more if we liked. We can also replicate the database. >> C) How do we settle on the distro/version of the month, this >> fundamental issue >> within Linux has always left me with a bad taste in my mouth. (this is a >> personal item and has nothing to say for the quality of FreeBSD or >> Linux/distro). > Unlike *BSD? Generally there have been distros like Debian and > Slackware that have been server grade for over 10 years and are > solid. I think the distro of the month is a unwarranted slam from > FreeBSD people who don't see that others see BSD the same way (Free, > Net, Open, etc) just with less choice for their respective > communities. There are lots of Linux distros. Some are better at the > desktop, some are better at the server. Coming up with a consensus of > what to use would be pretty easy to do. That being said, I don't > foresee a day that we'd use Linux just because everything else is > running on FreeBSD. Being consistent is a good thing. Well the distro of the month argument is a farse. We would use a well known linux distro and we would stick with it. We are primarily a Redhat/FC house and Ubuntu house. > >> D) How does doing something like this affect -core in general (I'm >> not part of >> core so i have no idea) >> > > I don't think it general does. PgFoundry is isolated away from -core. That is correct it doesn't effect core at all. Sincerely, Joshua D. Drake > > Regards, > > Gavin > > > ---------------------------(end of broadcast)--------------------------- > TIP 2: Don't 'kill -9' the postmaster -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: PLphp, PLperl - http://www.commandprompt.com/
On Monday 16 January 2006 14:17, Gavin M. Roy wrote: > > My concerns with a plan like this are: > > A) I do not know linux as well as FreeBSD. > > 80% of the Gforge admins are Linux guys afaik, which is why we need > more FreeBSD help. Which is why at least 2 more FreeBSD guys (Stefan and myself) were brought into the fold a while back. I can't speek for Stefan, but I have remained quite on this while I absorb the implementation specifics of the current setup. > > > B) Can infrastructure be provided to allow for timely disaster > > recovery in the > > event of JD's hosting falling off the face of the earth, (much the > > same way > > the pg servers in panama fell off a while ago). > > We don't have this *really* in the case of most of the > infrastructure, and this isn't in place for pgFoundry right now with > Marc hosting, afaik. It is an issue we should be concerned with > regardless of who's hosting. That and backup. I've tried to address > what's happening (or not happening as I'm afraid) with backup before. Wether we have it today or not is one thing, but making it even harder to do in the future without having a solid plan is even more troublesome in my opinion. Along this note, I know resources have been made available by Stefan and the company he works for to help address this. > > > C) How do we settle on the distro/version of the month, this > > fundamental issue > > within Linux has always left me with a bad taste in my mouth. (this > > is a > > personal item and has nothing to say for the quality of FreeBSD or > > Linux/distro). > > Unlike *BSD? Generally there have been distros like Debian and > Slackware that have been server grade for over 10 years and are > solid. I think the distro of the month is a unwarranted slam from > FreeBSD people who don't see that others see BSD the same way (Free, > Net, Open, etc) just with less choice for their respective > communities. There are lots of Linux distros. Some are better at > the desktop, some are better at the server. Coming up with a > consensus of what to use would be pretty easy to do. That being > said, I don't foresee a day that we'd use Linux just because > everything else is running on FreeBSD. Being consistent is a good > thing. For example we raninto an issue here were we ended up with 100% distro lock-in because of a hardware vendor only providing binary kernel modules for one specific distro and kernel version. Granted that is not a fault with "linux" in general, but it did mean I had to support some one ofs where consistency would have been the preferred norm. > > > D) How does doing something like this affect -core in general (I'm > > not part of > > core so i have no idea) > > I don't think it general does. PgFoundry is isolated away from -core. Note taken, thanks. > > Regards, > > Gavin > > _______________________________________________ > Gforge-admins mailing list > Gforge-admins@pgfoundry.org > http://pgfoundry.org/mailman/listinfo/gforge-admins -- Darcy Buskermolen Wavefire Technologies Corp. http://www.wavefire.com ph: 250.717.0200 fx: 250.763.1759
> Which is why at least 2 more FreeBSD guys (Stefan and myself) were brought > into the fold a while back. I can't speek for Stefan, but I have remained > quite on this while I absorb the implementation specifics of the current > setup. > Sure... but against 20 Linux people? No I don't have 20 specific people in mind but we are probably talking about an exponential difference here. > For example we raninto an issue here were we ended up with 100% distro > lock-in because of a hardware vendor only providing binary kernel modules for > one specific distro and kernel version. Granted that is not a fault with > "linux" in general, but it did mean I had to support some one ofs where > consistency would have been the preferred norm. > Well considering I would spec the hardware that is moot :) but I do get your point. I Sincerely, Joshua D. Drake -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: PLphp, PLperl - http://www.commandprompt.com/
On Mon, 16 Jan 2006, Gavin M. Roy wrote: >> My concerns with a plan like this are: >> A) I do not know linux as well as FreeBSD. > > 80% of the Gforge admins are Linux guys afaik, which is why we need more > FreeBSD help. > >> B) Can infrastructure be provided to allow for timely disaster recovery in >> the >> event of JD's hosting falling off the face of the earth, (much the same way >> the pg servers in panama fell off a while ago). > > We don't have this *really* in the case of most of the infrastructure, and > this isn't in place for pgFoundry right now with Marc hosting, afaik. All of the vServers that are being run on mirrored to both other servers, and other locations ... wwwmaster is mirrored back down to our core servers in Panama, and those running on those servers are mirrored to a secondary server within the same network, as well as offsite daily ... That has always been a requirement. ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Hi, On Mon, 2006-01-16 at 14:38 -0800, Joshua D. Drake wrote: > > Which is why at least 2 more FreeBSD guys (Stefan and myself) were brought > > into the fold a while back. I can't speek for Stefan, but I have remained > > quite on this while I absorb the implementation specifics of the current > > setup. > > > Sure... but against 20 Linux people? No I don't have 20 specific > people in mind but we are probably talking about an exponential > difference here. Well... If you need a "slave" to administrate the "candidate" pgfoundry Linux server, I'm here. Regards, -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
On Monday 16 January 2006 16:48, Marc G. Fournier wrote:
> On Mon, 16 Jan 2006, Robert Treat wrote:
> > based on my interaction with the foundry admins, afaict the single thing
> > stopping us from getting pgfoundry onto a new server is that we're
> > trying to do it on bsd (reread fetters' email for a good synopisis of
> > this). At what point do we decide moving forward is more important than
> > the os we are putting it on?
>
> Never,
we never decide that moving forward is more important than the os... that
explains some things....
> cause the longer it takes to move it, the less requirement there is
> to move it as I bring on better/more powerful servers *shrug*
>
> Within the next month or so, we'll have a new 64bit server going online,
> which I'll be able to move pgfoundry over to that has faster drives and
> more memory *shrug*
>
So if we procrastinate^h^h^hcan just hold out for another 2 months we can be
completely up and running with gforge on a quality dedicated bsd machine?
Cause I think we can be up and running in month on a linux box... now i dont
have anything against bsd so if you only need one extra month I'm happy with
that, but if you come back in three and say you need two more...
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
> So if we procrastinate^h^h^hcan just hold out for another 2 months we can be > completely up and running with gforge on a quality dedicated bsd machine? > Cause I think we can be up and running in month on a linux box... now i dont > have anything against bsd so if you only need one extra month I'm happy with > that, but if you come back in three and say you need two more... > > I would have us up and running on Linux before the end of January providing I had some help (with DNS etc..) Sincerely, Joshua D. Drake -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: PLphp, PLperl - http://www.commandprompt.com/
Joshua D. Drake wrote: > >> So if we procrastinate^h^h^hcan just hold out for another 2 months we >> can be completely up and running with gforge on a quality dedicated >> bsd machine? Cause I think we can be up and running in month on a >> linux box... now i dont have anything against bsd so if you only >> need one extra month I'm happy with that, but if you come back in >> three and say you need two more... >> > I would have us up and running on Linux before the end of January > providing I had some help (with DNS etc..) /me looks at calendar, o.k. maybe 1st week of Feb ;) Joshua D. Drake > > Sincerely, > > Joshua D. Drake > > > > -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: PLphp, PLperl - http://www.commandprompt.com/
On Mon, 16 Jan 2006, Robert Treat wrote: > So if we procrastinate^h^h^hcan just hold out for another 2 months we > can be completely up and running with gforge on a quality dedicated bsd > machine? Cause I think we can be up and running in month on a linux > box... now i dont have anything against bsd so if you only need one > extra month I'm happy with that, but if you come back in three and say > you need two more... to be totally honest, since it appears that there are no reasons why it can't be moved over to the existing server that was bought up for it, pgFoundry *could* be moved over to that tomorrow *shrug* The question has never been about moving it ... the problem, as far as I know, is that there seems to be a desire/requirement to do two steps in one: move pgfoundry to the new server *at the same time* as upgrading gForge to the latest version ... its not something I necessarily subscribe to, but JoshB was pushing for that one ... Moving pgFoundry over, as is, right now, is two rsync's, and a dump/reload of the database ... or, technically, should be ... it would require some downtime, I'm estimating about 3 hours since most of the copying would be done by the first rsync, with the second rsync running to just pull over any file changes since teh first rsync happened ... The longest part of the move would be upgrading the apps within the moved vServer to FreeBSD 6.x ... that involves, very simply: make installworld DESTDIR=<vserver directory> mergemaster -iD <vserver directory> and then once the vServer has been started, logging in and running: portupgrade -f /var/db/pkg/* to make sure all of the ports are upgraded ... in fact, if Sean has COMPAT4 enabled in the kernel, the portupgrade step itself doesn't *have* to be done, but the make installworld does, else ps doesn't work (procfs changes between 4.x and 6.x require it) ... Its not a particularly difficult thing to do, and could have been done *months* ago, but, again, the push seems to be for upgrading gForge at the same time, instead of doing it as two seperate steps ... As for the server that I'm working on right now ... yes, that will be in place *long* before 2 months is up ... I'm just waiting for a second CPU right now ... as for "quality server", we'll see how well HP holds up, but, so far, this box has very much impressed me ... anyone on these lists have experience with the HP Proliant DL* servers? The box I have here has built in virtual power and remote KVM ... no more having to get ahold of a tech to power cycle the server, I ssh into a dedicated interface for remote admin, type 'power reset' and the server power cycles itself ... I've configured this box with it sitting in the other room without a monitor/keyboard attached to it, and no 'extra/special hardware' ... So, yes, if the server that was bought for pgfoundry has to wait until JoshB et al are ready for the 'next version of gForge', pgFoundry.org will be moved up to this server when it comes online, following the exact upgrade steps I outlined above for moving it to its dedicated server ... Personally, though, I'd rather just move it to the box in Sean's location, and do the gForge upgrade as a second step, vs doing them both at the same time, and move postgresql.org to the new 64bit server I'm putting down there instead *shrug* But, pgfoundry is the more visible of the two ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Mon, Jan 16, 2006 at 12:21:47PM -0800, David Fetter wrote: > Command Prompt has people on call 24/7, and Josh Drake has mentioned > to me that their absolute worst situation so far resulted in four > hours of downtime. And having dedicated people at the data center is very important, right behind having a data center that's designed so that you don't need those folks around to begin with. I'm not sure why going with CMD means this has to be on linux. Surely someone there could get a box up and running FBSD to the point where someone remote could finish install and config. Or just ship a pre-installed box there... While on the subject, I'm a FreeBSD guy as well and can help with this stuff. In any case, trying to run pgFoundry in a jail with a bunch of other things on the machine (which from what I gather is the current state of affairs) seems folly. I guess I can see using jail if it makes failover easy (I've never used it myself, but I don't know of any reason why it'd add appreciable overhead), but trying to run something that big in a shared environment is pretty silly. If anything I'd say it's big enough that there should be more than one machine hosting it, such as database server, webserver, shell/SCM server. I know there's a lot to be said for everything running on the same OS, but the fact is pgFoundry has been sucking wind to various degrees for months now; if we can't fix that quickly while staying on FBSD and we've got offers to handle OS-level admin then we need to look at moving. What we can't do is let this drag on for another year. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
> I'm not sure why going with CMD means this has to be on linux. Because we are a Linux shop it has nothing to do with FBSD as much as it has everything to do with Linux. As I said earlier I can run FBSD, I prefer Linux. Having one OS in the facility greatly decreases costs in maintenance, administration etc.. and allows us to keep up to date on important things easier. > Surely > someone there could get a box up and running FBSD to the point where > someone remote could finish install and config. Or just ship a > pre-installed box there... Sure and I could easily do so myself but see above. > > affairs) seems folly. I guess I can see using jail if it makes failover > easy (I've never used it myself, but I don't know of any reason why it'd > add appreciable overhead), Well done correctly a jail isn't any more useful then a standard server, shared or otherwise. It is just a matter of documentation and scripting. > but trying to run something that big in a > shared environment is pretty silly. If anything I'd say it's big enough > that there should be more than one machine hosting it, such as database > server, webserver, shell/SCM server. It should be noted that Pgfoundry does not take a ton of resources at this time. Although having it on a machine with almost 50 other vms is quite silly. > I know there's a lot to be said for everything running on the same OS, > but the fact is pgFoundry has been sucking wind to various degrees for > months now; if we can't fix that quickly while staying on FBSD and we've > got offers to handle OS-level admin then we need to look at moving. What > we can't do is let this drag on for another year. That is kind of my point. Sincerely, Joshua D. Drake -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: PLphp, PLperl - http://www.commandprompt.com/
On Mon, Jan 16, 2006 at 04:13:51PM -0800, Joshua D. Drake wrote: > > >I'm not sure why going with CMD means this has to be on linux. > Because we are a Linux shop it has nothing to do with FBSD > as much as it has everything to do with Linux. As I said earlier > I can run FBSD, I prefer Linux. > > Having one OS in the facility greatly decreases costs in maintenance, > administration etc.. and allows us to keep up to date on important > things easier. Sure, but the flip-side is that there really shouldn't be any need for anyone on-site to need to touch the OS itself. For example, distributed.net has run boxes all over the place for years and I think we've only twice needed human intervention at the console due to software, and that was only because we didn't have a hardware-based serial console. Of course I'm sure you guys have a bunch of OS and application level monitoring you can do if it's on linux, but if the folks who are running this stuff would rather roll that themselves I have no problem with that. Ultimately, everyone's motivation in OSS is different; if the folks running pgFoundry enjoy doing so because it's on FBSD that's fine with me, so long as stuff is working well. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
> > Sure, but the flip-side is that there really shouldn't be any need for > anyone on-site to need to touch the OS itself. For example, > distributed.net has run boxes all over the place for years and I think > we've only twice needed human intervention at the console due to > software, and that was only because we didn't have a hardware-based > serial console. And when the hard drive dies? > Ultimately, everyone's motivation in OSS is different; if the folks > running pgFoundry enjoy doing so because it's on FBSD that's fine with > me, so long as stuff is working well. Ahh but most of the folks running pgFoundry are Linux people ;)... Joshua D. Drake -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: PLphp, PLperl - http://www.commandprompt.com/
On Mon, 16 Jan 2006, Joshua D. Drake wrote: >> but trying to run something that big in a >> shared environment is pretty silly. If anything I'd say it's big enough >> that there should be more than one machine hosting it, such as database >> server, webserver, shell/SCM server. > It should be noted that Pgfoundry does not take a ton of resources > at this time. Although having it on a machine with almost 50 other > vms is quite silly. Obviously you haven't been keeping track of #s ... there are currently 27 vServers on that machine right now, and it will never get higher then 30 ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Marc G. Fournier wrote:
> On Mon, 16 Jan 2006, Joshua D. Drake wrote:
>
>>> but trying to run something that big in a
>>> shared environment is pretty silly. If anything I'd say it's big enough
>>> that there should be more than one machine hosting it, such as database
>>> server, webserver, shell/SCM server.
>> It should be noted that Pgfoundry does not take a ton of resources
>> at this time. Although having it on a machine with almost 50 other
>> vms is quite silly.
>
> Obviously you haven't been keeping track of #s ... there are currently
> 27 vServers on that machine right now, and it will never get higher
> then 30 ...
cmd@pgfoundry$ df -m|grep -i "/vm/"|wc
45 270 3778
cmd@pgfoundry$
Although to be fair, many of those are appear to be duplicate for /usr/ports
Sincerely,
Joshua D. Drake
>
> ----
> Marc G. Fournier Hub.Org Networking Services
> (http://www.hub.org)
> Email: scrappy@hub.org Yahoo!: yscrappy ICQ:
> 7615664
--
The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: PLphp, PLperl - http://www.commandprompt.com/
On Mon, 16 Jan 2006, Joshua D. Drake wrote: > Marc G. Fournier wrote: >> On Mon, 16 Jan 2006, Joshua D. Drake wrote: >> >>>> but trying to run something that big in a >>>> shared environment is pretty silly. If anything I'd say it's big enough >>>> that there should be more than one machine hosting it, such as database >>>> server, webserver, shell/SCM server. >>> It should be noted that Pgfoundry does not take a ton of resources >>> at this time. Although having it on a machine with almost 50 other >>> vms is quite silly. >> >> Obviously you haven't been keeping track of #s ... there are currently 27 >> vServers on that machine right now, and it will never get higher then 30 >> ... > cmd@pgfoundry$ df -m|grep -i "/vm/"|wc > 45 270 3778 > cmd@pgfoundry$ > > Although to be fair, many of those are appear to be duplicate for > /usr/ports Actually, if you want to see a full df of that server, I've included it below. the ones that state '<below>:/vm/..' are the uniofs mount that we are working on getting rid of as fast as clients permit us to ... the proc mount points are required for ps ... and teh du at the bottom is an nfs mount use to negate the unionfs to calculate storage used, and once unionfs is gone, is no longer used for anything ... and the /usr/ports nfs mounts are just that ... /usr/ports mounted into a vServer in order to install ... you'd be better to do 'df -m | grep procfs' to find out # of vServers currently running ... # of mount points != # of vservers ... # df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/da0s1a 516062 129040 345738 27% / /dev/da0s1e 516062 1920 472858 0% /tmp /dev/da0s1g 5161198 1794014 2954290 38% /usr /dev/da0s1f 516062 98880 375898 21% /var procfs 4 4 0 100% /proc /dev/da0s1h 217783448 90481636 109879138 45% /vm procfs 4 4 0 100% /vm/141/mylston.com/proc <below>:/vm/.t2/usr 435566896 308265084 109879138 74% /vm/141/mylston.com/usr procfs 4 4 0 100% /vm/250/hantscounty.com/proc <below>:/vm/.t2/usr 435566896 308265084 109879138 74% /vm/250/hantscounty.com/usr procfs 4 4 0 100% /vm/313/adventsystems.com.au/proc <below>:/vm/.t2/usr 435566896 308265084 109879138 74% /vm/313/adventsystems.com.au/usr procfs 4 4 0 100% /vm/330/metalexis.com/proc <below>:/vm/.t2/usr 435566896 308265084 109879138 74% /vm/330/metalexis.com/usr procfs 4 4 0 100% /vm/360/keytoyourfuture.com/proc <below>:/vm/.t2/usr 435566896 308265084 109879138 74% /vm/360/keytoyourfuture.com/usr procfs 4 4 0 100% /vm/366/munmed.ca/proc <below>:/vm/.t2/usr 435566896 308265084 109879138 74% /vm/366/munmed.ca/usr procfs 4 4 0 100% /vm/477/rxvaluecanada.com/proc <below>:/vm/.t4/usr 435566896 308265084 109879138 74% /vm/477/rxvaluecanada.com/usr procfs 4 4 0 100% /vm/485/jsengine.net/proc <below>:/vm/.t3/usr 435566896 308265084 109879138 74% /vm/485/jsengine.net/usr procfs 4 4 0 100% /vm/493/consultmydebt.com/proc <below>:/vm/.t2/usr 435566896 308265084 109879138 74% /vm/493/consultmydebt.com/usr procfs 4 4 0 100% /vm/583/piratesofwarcraft.org/proc <below>:/vm/.t2/usr 435566896 308265084 109879138 74% /vm/583/piratesofwarcraft.org/usr procfs 4 4 0 100% /vm/587/zonekom.com/proc <below>:/vm/.t4/usr 435566896 308265084 109879138 74% /vm/587/zonekom.com/usr procfs 4 4 0 100% /vm/645/prograin.qc.ca/proc <below>:/vm/.t3/usr 435566896 308265084 109879138 74% /vm/645/prograin.qc.ca/usr procfs 4 4 0 100% /vm/659/ipodderx.com/proc <below>:/vm/.t11/usr 435566896 308265084 109879138 74% /vm/659/ipodderx.com/usr procfs 4 4 0 100% /vm/675/processintelligence.com/proc <below>:/vm/.t17/usr 435566896 308265084 109879138 74% /vm/675/processintelligence.com/usr procfs 4 4 0 100% /vm/372/itf-nigeria.org/proc procfs 4 4 0 100% /vm/562/gpmpdb.net/proc <below>:/vm/.t2/usr 435566896 308265084 109879138 74% /vm/562/gpmpdb.net/usr procfs 4 4 0 100% /vm/671/timedeskblog.com/proc procfs 4 4 0 100% /vm/709/cwassociates.ca/proc procfs 4 4 0 100% /vm/434/beta.ballroomregistrar.com/proc procfs 4 4 0 100% /vm/1/mx1.hub.org/proc procfs 4 4 0 100% /vm/664/balatongroup.org/proc <below>:/vm/.t16/usr 435566896 308265084 109879138 74% /vm/664/balatongroup.org/usr procfs 4 4 0 100% /vm/714/uberbaud.net/proc procfs 4 4 0 100% /vm/41/saranadeau.com/proc procfs 4 4 0 100% /vm/186/pgfoundry.org/proc mercury:/usr/ports 5161198 1794014 2954290 38% /vm/186/pgfoundry.org/usr/ports procfs 4 4 0 100% /vm/1/maildb.hub.org/proc procfs 4 4 0 100% /vm/642/chicagosmallbiz.com/proc procfs 4 4 0 100% /vm/502/julienjaborska.com/proc mercury:/usr/ports 5161198 1794014 2954290 38% /vm/502/julienjaborska.com/usr/ports mercury.hub.org:/vm 217783448 90481636 109879138 45% /du ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Monday 16 January 2006 18:59, Marc G. Fournier wrote:
> On Mon, 16 Jan 2006, Robert Treat wrote:
> > So if we procrastinate^h^h^hcan just hold out for another 2 months we
> > can be completely up and running with gforge on a quality dedicated bsd
> > machine? Cause I think we can be up and running in month on a linux
> > box... now i dont have anything against bsd so if you only need one
> > extra month I'm happy with that, but if you come back in three and say
> > you need two more...
>
> to be totally honest, since it appears that there are no reasons why it
> can't be moved over to the existing server that was bought up for it,
> pgFoundry *could* be moved over to that tomorrow *shrug*
>
> The question has never been about moving it ... the problem, as far as I
> know, is that there seems to be a desire/requirement to do two steps in
> one: move pgfoundry to the new server *at the same time* as upgrading
> gForge to the latest version ... its not something I necessarily subscribe
> to, but JoshB was pushing for that one ...
>
*sigh* you ask the software guys what the problem is and they say hardware/os.
you ask the hardware/os guy what the problem is and he says software. You ask
joshua and he says first week of february. sounds like we should go cmd/linux
to me
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
> As for the server that I'm working on right now ... yes, that
> will be in place *long* before 2 months is up ... I'm just
> waiting for a second CPU right now ... as for "quality
> server", we'll see how well HP holds up, but, so far, this
> box has very much impressed me ... anyone on these lists have
> experience with the HP Proliant DL* servers? The box I have
> here has built in virtual power and remote KVM ... no more
> having to get ahold of a tech to power cycle the server, I
> ssh into a dedicated interface for remote admin, type 'power
> reset' and the server power cycles itself ...
> I've configured this box with it sitting in the other room
> without a monitor/keyboard attached to it, and no
> 'extra/special hardware' ...
Sure, been using them for years. Never had a single problem (well,
failed harddrive of course - statistically, that *will* happen on any
brand given enough disks... The hw raid has dealt with it with zero
problems though).
Luke (I think it is) keeps saying the performance of the RAID cards are
bad in linux, though. I haven't had that experience myself (I've had
great performance), but I probably don't push them as hard as he does.
Just make sure you have the battery-backed-cache option (which really
should be standard, but isn't unless you've bought one of the high-end
extra RAID controllers).
They provide both commercial and OSS drivers for all hardware when ti
comes to Linux. Everything has worked perfectly for me except the RILOE
driver which doesn't work on 2.6 unless you run RedHat or SuSE (because
they have patched the kernel so horribly much it's no longer near what
the standard kernel is). On 2.6 it works fine. The only thing you really
lose without this driver is the ability to relay SNMP requests thruogh
the iLO interfaces into the machine without going across the public
network (good for machiens in DMZs or outside FWs, as SNMP is less than
ideal from a security standpoint)
Never tried with FreeBSD. Do they include their full management tools
for that ("Insight Management Agents" I think they call it)? (Such as
pre-failure detection for HD, RAM, CPU etc that their techs will
actually accept as enough for a replacement without questioning etc)
//Magnus
> > Sure, but the flip-side is that there really shouldn't be > any need for > > anyone on-site to need to touch the OS itself. For example, > > distributed.net has run boxes all over the place for years > and I think > > we've only twice needed human intervention at the console due to > > software, and that was only because we didn't have a hardware-based > > serial console. > And when the hard drive dies? Why would you need to go into the OS console for that? Just replace the broken harddrive and be done with it? You need physical access to the machine of course, but the OS should be no difference. Heck, it makes no difference between Linux and *Windows* for that here, and FreeBSD is definitly closer ;-) //Magnus
Guys, As the person who put $900 of his personal money into the server we're working on, let me say that I'm in favor of *whatever* gets pgFoundry moved to a new, fast, dedicated machine -- especially if it can be done using the time of people who aren't taking that time away from other community tasks. Please let me know, though, *before* I fork out $230 for another HDD for this machine, thanks. JD, I think, though, that you may be underestimating the rather involved nature of a GForge install. Especially if we want to provide semi-secure "sandboxes" for the projects, which was one of the goals of moving to a new machine. If we put pgFoundry somewhere else, I'm sure we can find a place for another fast FBSD6 machine in the network of PostgreSQL servers. --Josh
People, > I belive marc dod make this suggestion, and I can;t see any reason not to try > that now that we (you and I specificaly) are more familiar with how it all > goes together than we were a month ago. If I'm not mistakin Josh B had > pgfoundry.com available for pointing at the new box (if it's not already) > baring any objections from the rest of our cohorts, this sounds like a > reasonable thing to try, to see if infact it is this easy, or if there are > some unforeseen hickups along the way... Go for it. Just try not to wipe out the Bizgres.org partition. --Josh
Thank you ... will co-ordinate this on the gforge admins mailing list and see if we can get this done yesterday :) On Tue, 17 Jan 2006, Josh Berkus wrote: > People, > >> I belive marc dod make this suggestion, and I can;t see any reason not to >> try that now that we (you and I specificaly) are more familiar with how it >> all goes together than we were a month ago. If I'm not mistakin Josh B had >> pgfoundry.com available for pointing at the new box (if it's not already) >> baring any objections from the rest of our cohorts, this sounds like a >> reasonable thing to try, to see if infact it is this easy, or if there are >> some unforeseen hickups along the way... > > Go for it. Just try not to wipe out the Bizgres.org partition. > > --Josh > > ---------------------------(end of broadcast)--------------------------- > TIP 3: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faq > ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Darcy Buskermolen wrote: > On Monday 16 January 2006 14:17, Gavin M. Roy wrote: > >>>My concerns with a plan like this are: >>>A) I do not know linux as well as FreeBSD. >> >>80% of the Gforge admins are Linux guys afaik, which is why we need >>more FreeBSD help. > > > Which is why at least 2 more FreeBSD guys (Stefan and myself) were brought > into the fold a while back. I can't speek for Stefan, but I have remained > quite on this while I absorb the implementation specifics of the current > setup. very true - it is always a bit difficult to get familiar with foreign boxes, but I think we are rapidly getting near a point where the current setup is understood and can be managed, upgraded and (likely) improved. > > >>>B) Can infrastructure be provided to allow for timely disaster >>>recovery in the >>>event of JD's hosting falling off the face of the earth, (much the >>>same way >>>the pg servers in panama fell off a while ago). >> >>We don't have this *really* in the case of most of the >>infrastructure, and this isn't in place for pgFoundry right now with >>Marc hosting, afaik. It is an issue we should be concerned with >>regardless of who's hosting. That and backup. I've tried to address >>what's happening (or not happening as I'm afraid) with backup before. > > > Wether we have it today or not is one thing, but making it even harder to do > in the future without having a solid plan is even more troublesome in my > opinion. fully agreed > > Along this note, I know resources have been made available by Stefan and the > company he works for to help address this. yep - I have offered in the past and that offer still stands for hardware/hosting/bandwidth (including decent network monitoring, remote console/power and people 24x7 on-call) for whatever the community might need (backup-server in europe or whatever). And no - I don't particularly care if the box is running FreeBSD or some Linux-Distribution(we have all of them - and Solaris,AIX and OpenBSD too - here and each of those has it's strengths and weaknesses). It's just that the current setup works on FreeBSD and afaik is not (unfixable) broken. Maybe we (I could do it if marc agrees) should just try to rsync the running vm to the "new" box upgrade it inplace to fbsd6 start it up and test it and see what breaks. If that works reasonably well we at least have a useful emergency plan for NOW - independent of what happens(OS,Hosting or admin-wise) in the "long" (1-2 month+) run. Stefan
On Tuesday 17 January 2006 09:51, Stefan Kaltenbrunner wrote: > Darcy Buskermolen wrote: > > On Monday 16 January 2006 14:17, Gavin M. Roy wrote: > >>>My concerns with a plan like this are: > >>>A) I do not know linux as well as FreeBSD. > >> > >>80% of the Gforge admins are Linux guys afaik, which is why we need > >>more FreeBSD help. > > > > Which is why at least 2 more FreeBSD guys (Stefan and myself) were > > brought into the fold a while back. I can't speek for Stefan, but I have > > remained quite on this while I absorb the implementation specifics of the > > current setup. > > very true - it is always a bit difficult to get familiar with foreign > boxes, but I think we are rapidly getting near a point where the current > setup is understood and can be managed, upgraded and (likely) improved. > > >>>B) Can infrastructure be provided to allow for timely disaster > >>>recovery in the > >>>event of JD's hosting falling off the face of the earth, (much the > >>>same way > >>>the pg servers in panama fell off a while ago). > >> > >>We don't have this *really* in the case of most of the > >>infrastructure, and this isn't in place for pgFoundry right now with > >>Marc hosting, afaik. It is an issue we should be concerned with > >>regardless of who's hosting. That and backup. I've tried to address > >>what's happening (or not happening as I'm afraid) with backup before. > > > > Wether we have it today or not is one thing, but making it even harder to > > do in the future without having a solid plan is even more troublesome in > > my opinion. > > fully agreed > > > Along this note, I know resources have been made available by Stefan and > > the company he works for to help address this. > > yep - I have offered in the past and that offer still stands for > hardware/hosting/bandwidth (including decent network monitoring, remote > console/power and people 24x7 on-call) for whatever the community might > need (backup-server in europe or whatever). > And no - I don't particularly care if the box is running FreeBSD or some > Linux-Distribution(we have all of them - and Solaris,AIX and OpenBSD too > - here and each of those has it's strengths and weaknesses). > It's just that the current setup works on FreeBSD and afaik is not > (unfixable) broken. Maybe we (I could do it if marc agrees) should just > try to rsync the running vm to the "new" box upgrade it inplace to fbsd6 > start it up and test it and see what breaks. I belive marc dod make this suggestion, and I can;t see any reason not to try that now that we (you and I specificaly) are more familiar with how it all goes together than we were a month ago. If I'm not mistakin Josh B had pgfoundry.com available for pointing at the new box (if it's not already) baring any objections from the rest of our cohorts, this sounds like a reasonable thing to try, to see if infact it is this easy, or if there are some unforeseen hickups along the way... > If that works reasonably well we at least have a useful emergency plan > for NOW - independent of what happens(OS,Hosting or admin-wise) in the > "long" (1-2 month+) run. > > > Stefan > _______________________________________________ > Gforge-admins mailing list > Gforge-admins@pgfoundry.org > http://pgfoundry.org/mailman/listinfo/gforge-admins -- Darcy Buskermolen Wavefire Technologies Corp. http://www.wavefire.com ph: 250.717.0200 fx: 250.763.1759