Re: PgFoundry Move

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(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664