Thread: PgFoundry Move

PgFoundry Move

From
"Joshua D. Drake"
Date:
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/


Re: PgFoundry Move

From
"Marc G. Fournier"
Date:
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

Re: [Gforge-admins] Re: PgFoundry Move

From
Andrew Dunstan
Date:
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


Re: [Gforge-admins] Re: PgFoundry Move

From
"Marc G. Fournier"
Date:
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

Re: PgFoundry Move

From
David Fetter
Date:
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!

Re: PgFoundry Move

From
"Magnus Hagander"
Date:
<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

Re: [Gforge-admins] Re: PgFoundry Move

From
"Joshua D. Drake"
Date:
>> - 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/


Re: PgFoundry Move

From
"Joshua D. Drake"
Date:
> 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/


Re: PgFoundry Move

From
"Marc G. Fournier"
Date:
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

Re: PgFoundry Move

From
"Joshua D. Drake"
Date:
>
> 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/


Re: PgFoundry Move

From
Guido Barosio
Date:
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 .
/ \ -----------------------------------------------------------------

Re: PgFoundry Move

From
"Magnus Hagander"
Date:
> 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

Re: PgFoundry Move

From
Robert Treat
Date:
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

Re: PgFoundry Move

From
"Marc G. Fournier"
Date:
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

Re: [Gforge-admins] PgFoundry Move

From
Darcy Buskermolen
Date:
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

Re: [Gforge-admins] Re: PgFoundry Move

From
Darcy Buskermolen
Date:
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

Re: [Gforge-admins] PgFoundry Move

From
"Gavin M. Roy"
Date:
> 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


Re: [Gforge-admins] PgFoundry Move

From
"Joshua D. Drake"
Date:
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/


Re: [Gforge-admins] PgFoundry Move

From
Darcy Buskermolen
Date:
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

Re: [Gforge-admins] PgFoundry Move

From
"Joshua D. Drake"
Date:
> 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/


Re: [Gforge-admins] PgFoundry Move

From
"Marc G. Fournier"
Date:
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

Re: [Gforge-admins] PgFoundry Move

From
Devrim GUNDUZ
Date:
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/



Re: PgFoundry Move

From
Robert Treat
Date:
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

Re: PgFoundry Move

From
"Joshua D. Drake"
Date:
> 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/


Re: [Gforge-admins] Re: PgFoundry Move

From
"Joshua D. Drake"
Date:
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/


Re: PgFoundry Move

From
"Marc G. Fournier"
Date:
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

Re: PgFoundry Move

From
"Jim C. Nasby"
Date:
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

Re: PgFoundry Move

From
"Joshua D. Drake"
Date:
> 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/


Re: PgFoundry Move

From
"Jim C. Nasby"
Date:
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

Re: PgFoundry Move

From
"Joshua D. Drake"
Date:
>
> 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/


Re: PgFoundry Move

From
"Marc G. Fournier"
Date:
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

Re: PgFoundry Move

From
"Joshua D. Drake"
Date:
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/


Re: PgFoundry Move

From
"Marc G. Fournier"
Date:
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

Re: PgFoundry Move

From
Robert Treat
Date:
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

Re: PgFoundry Move

From
"Magnus Hagander"
Date:
> 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

Re: PgFoundry Move

From
"Magnus Hagander"
Date:
> > 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

Re: [Gforge-admins] Re: PgFoundry Move

From
Josh Berkus
Date:
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





Re: [Gforge-admins] PgFoundry Move

From
Josh Berkus
Date:
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

Re: [Gforge-admins] PgFoundry Move

From
"Marc G. Fournier"
Date:
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

Re: [Gforge-admins] PgFoundry Move

From
Stefan Kaltenbrunner
Date:
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

Re: [Gforge-admins] PgFoundry Move

From
Darcy Buskermolen
Date:
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