Subject: PgFoundry Move

From: "Joshua D. Drake" <[email-masked]>
Date: Mon, 16 Jan 2006 10:26:06 -0800

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/

---

From: "Marc G. Fournier" <[email-masked]>
Date: Mon, 16 Jan 2006 14:59:29 -0400 (AST)

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:

> The longest outage we have had that was global in the last 24 months (that 
> wasn't
> ---------------------------(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: [email-masked]           Yahoo!: yscrappy              ICQ: 7615664

---

From: Andrew Dunstan <[email-masked]>
Date: Mon, 16 Jan 2006 14:58:11 -0500

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:
> _______________________________________________
> Gforge-admins mailing list
> [email-masked]
> http://pgfoundry.org/mailman/listinfo/gforge-admins

---

From: "Marc G. Fournier" <[email-masked]>
Date: Mon, 16 Jan 2006 16:17:47 -0400 (AST)

> - 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 ...

> 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 ...

> 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 ...

----

---

From: David Fetter <[email-masked]>
Date: Mon, 16 Jan 2006 12:21:47 -0800

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 [email-masked] http://fetter.org/
phone: +1 415 235 3778

Remember to vote!

---

From: "Joshua D. Drake" <[email-masked]>
Date: Mon, 16 Jan 2006 12:30:50 -0800

> Wasn't Joshua planning on fixing that?
For the migration yes. I haven't touched the current machine as it is 
production.

> 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.

> 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

---

From: "Marc G. Fournier" <[email-masked]>
Date: Mon, 16 Jan 2006 16:33:17 -0400 (AST)

> to me that their absolute worst situation so far resulted in four

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 ...

----

---

From: "Joshua D. Drake" <[email-masked]>
Date: Mon, 16 Jan 2006 12:36:43 -0800

> 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

---

From: Robert Treat <[email-masked]>
Date: Mon, 16 Jan 2006 16:37:28 -0500

> 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

---

From: "Marc G. Fournier" <[email-masked]>
Date: Mon, 16 Jan 2006 17:48:00 -0400 (AST)

On Mon, 16 Jan 2006, Robert Treat wrote:

> 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*

----

---

From: Darcy Buskermolen <[email-masked]>
Date: Mon, 16 Jan 2006 13:51:48 -0800

> 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....

-- 
Darcy Buskermolen
Wavefire Technologies Corp.

http://www.wavefire.com
ph: 250.717.0200
fx: 250.763.1759

---

From: Darcy Buskermolen <[email-masked]>
Date: Mon, 16 Jan 2006 13:57:09 -0800

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)

http://www.wavefire.com
ph: 250.717.0200
fx: 250.763.1759

---

From: "Gavin M. Roy" <[email-masked]>
Date: Mon, 16 Jan 2006 14:17:03 -0800

> 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.

> 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.

> personal item and has nothing to say for the quality of FreeBSD or

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  

I don't think it general does.  PgFoundry is isolated away from -core.

Regards,

Gavin

---

From: "Joshua D. Drake" <[email-masked]>
Date: Mon, 16 Jan 2006 14:25:43 -0800

> 80% of the Gforge admins are Linux guys afaik, which is why we need 
Correct but the pool of Linux helpers is getting larger by the day. FreeBSD
isn't, at least not at nearly the same rate.

> 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.

> 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.

> 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
> TIP 2: Don't 'kill -9' the postmaster

---

From: Darcy Buskermolen <[email-masked]>
Date: Mon, 16 Jan 2006 14:31:41 -0800

> 80% of the Gforge admins are Linux guys afaik, which is why we need

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.

> 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.

> everything else is running on FreeBSD.  Being consistent is a good

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.

> I don't think it general does.  PgFoundry is isolated away from -core.

Note taken, thanks.

http://www.wavefire.com
ph: 250.717.0200
fx: 250.763.1759

---

From: "Joshua D. Drake" <[email-masked]>
Date: Mon, 16 Jan 2006 14:38:59 -0800

> quite on this while I absorb the implementation specifics of the current 
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.

> 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

---

From: "Marc G. Fournier" <[email-masked]>
Date: Mon, 16 Jan 2006 18:58:36 -0400 (AST)

On Mon, 16 Jan 2006, Gavin M. Roy wrote:

> 80% of the Gforge admins are Linux guys afaik, which is why we need more 
> FreeBSD help.
>
> 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.

----

---

From: Devrim GUNDUZ <[email-masked]>
Date: Tue, 17 Jan 2006 01:27:46 +0200

Hi,

> people in mind but we are probably talking about an exponential

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/

---

From: Robert Treat <[email-masked]>
Date: Mon, 16 Jan 2006 18:36:37 -0500

On Monday 16 January 2006 16:48, Marc G. Fournier wrote:
> 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 

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...

---

From: "Joshua D. Drake" <[email-masked]>
Date: Mon, 16 Jan 2006 15:40:39 -0800

> 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

---

From: "Joshua D. Drake" <[email-masked]>
Date: Mon, 16 Jan 2006 15:43:33 -0800

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...
>>   
/me looks at calendar, o.k. maybe 1st week of Feb ;)

Joshua D. Drake

---

From: "Marc G. Fournier" <[email-masked]>
Date: Mon, 16 Jan 2006 19:59:00 -0400 (AST)

On Mon, 16 Jan 2006, Robert Treat wrote:

> 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 ...

----

---

From: "Jim C. Nasby" <[email-masked]>
Date: Mon, 16 Jan 2006 18:02:07 -0600

> to me that their absolute worst situation so far resulted in four

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      [email-masked]
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461

---

From: "Joshua D. Drake" <[email-masked]>
Date: Mon, 16 Jan 2006 16:13:51 -0800

> 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
> pre-installed box there...
Sure and I could easily do so myself but see above.

> 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
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.

> we can't do is let this drag on for another year.
That is kind of my point.

Sincerely,

Joshua D. Drake

---

From: "Jim C. Nasby" <[email-masked]>
Date: Mon, 16 Jan 2006 18:24:59 -0600

> administration etc.. and allows us to keep up to date on important

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      [email-masked]
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461

---

From: "Marc G. Fournier" <[email-masked]>
Date: Mon, 16 Jan 2006 20:29:06 -0400 (AST)

> at this time. Although having it on a machine with almost 50 other

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 
...

----

---

From: "Joshua D. Drake" <[email-masked]>
Date: Mon, 16 Jan 2006 16:29:28 -0800

> software, and that was only because we didn't have a hardware-based
And when the hard drive dies?

> me, so long as stuff is working well.

Ahh but most of the folks running pgFoundry are Linux people ;)...

Joshua D. Drake

---

From: "Joshua D. Drake" <[email-masked]>
Date: Mon, 16 Jan 2006 16:35:12 -0800

Marc G. Fournier wrote:
> 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

---

From: "Marc G. Fournier" <[email-masked]>
Date: Mon, 16 Jan 2006 20:43:37 -0400 (AST)

> cmd@pgfoundry$ df -m|grep -i "/vm/"|wc

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

----

---

From: Robert Treat <[email-masked]>
Date: Mon, 16 Jan 2006 19:49:41 -0500

> 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

---

From: Stefan Kaltenbrunner <[email-masked]>
Date: Tue, 17 Jan 2006 18:51:38 +0100

> quite on this while I absorb the implementation specifics of the current 

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.

> in the future without having a solid plan is even more troublesome in my 

fully agreed

> 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

---

From: Josh Berkus <[email-masked]>
Date: Tue, 17 Jan 2006 10:11:11 -0800

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

---

From: Josh Berkus <[email-masked]>
Date: Tue, 17 Jan 2006 10:12:47 -0800

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

---

From: Darcy Buskermolen <[email-masked]>
Date: Tue, 17 Jan 2006 10:13:18 -0800

On Tuesday 17 January 2006 09:51, Stefan Kaltenbrunner 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.
>
> > 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.
>

http://www.wavefire.com
ph: 250.717.0200
fx: 250.763.1759

---

From: "Marc G. Fournier" <[email-masked]>
Date: Tue, 17 Jan 2006 14:44:01 -0400 (AST)

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 
> TIP 3: Have you checked our extensive FAQ?
>
>              http://www.postgresql.org/docs/faq
>

----