|
|
| Author |
Message |
| 25 new of 547 responses total. |
bhoward
|
|
response 500 of 547:
| 
Oct 26 02:51 UTC 2003 |
Other structural issues such as those raised by Mary (in #463) and
others need to be discussed but that really ought to be
separated from discussion on the tactics of getting nextgrex into
production as soon as possible.
Seems to me you have X amount of work waiting to be done, Y number of
staff trusted and capable of doing this kind of work and only a subset
available to do it.
We want to promote nextgrex into production in as little time T as
possible. How much time that is can (and has) be(en) argued but it
remains that to reduce the time you can:
1) Reduce the amount of work required for go live
Possible. Depends on what is critical-path. Throwing in
non-critical-path distractions like replacing Picospan as was suggested by
someone earlier does little to reduce T. Shortcuts may be an option
in some areas, but must be weighed against security/integrity
risks and a call made whether the deferred cost in staff time (remember
short cuts need to be cleaned up) is worth it. Personally, I'm willing
to give up some time to insure our new system is well documented, stable
and secure.
2) Increase the number of people working on the upgrade
This is tougher. You can't just expand the pool of trusted technical
staff overnight. Trust is something earned over time and a track record
of delivering.
Basically to reduce T here we either discover underutilized people
resources within the existing group of trusted or semitrusted staff, or
possibly implement some system of work delegation non-staff volunteers
that applies limited staff time to reviewing work done by them. However,
there may practical limitations on the value of mixing in more people
or farming out the work.
Moving forward, we should take a hard look how to redistribute technical
responsibilities to reduce the pressure on individual staff and avoid
single points of failure but our options for the immediate term are
limited by the above. From what I gather, the main tasks remaining are:
* Recompile Picospan for OpenBSD
* Setup newuser
* Configuration tuning, whatever smallish tasks janc refers to in #472.
* Mail
* Transfer the data
Mail seems to be the only significant one. Perhaps we can sort out an
agreement from Jan and Marcus that Dan move ahead on what he would like
to do with the understanding he document as he builds it out and they
make some time to review.
For the record, if there are tasks that can be delegated to non-staff,
please add my name to the roster of volunteers.
My apologies for letting this get so long. Price of having lurked for
so long, I guess :-)
|
gelinas
|
|
response 501 of 547:
|
Oct 26 03:02 UTC 2003 |
(I thought I had heard that Marcus has already compiled Picospan for OpenBSD.
He'll probably have to do it again, before the migration, but it doesn't seem
to be a show-stopper.)
|
gull
|
|
response 502 of 547:
|
Oct 26 03:21 UTC 2003 |
My understanding is that OpenBSD is totally changing their binary format and
breaking backwards compatibility, so it will have to be recompiled.
However, if he's already compiled it once, there's probably nothing
time-consuming to do.
|
cross
|
|
response 503 of 547:
|
Oct 26 03:54 UTC 2003 |
Regarding #500; Well, I think there are some things we can seriously
cut down on to save time. For instance, we don't need to build out
a complex authentication system using Kerberos right now. The reason
for trying to use something other than PicoSpan is to cut down on time
(Marcus isn't around a lot these days), and partly because using software
we don't have the source for is going to cause problems as time goes on.
For instance, it'd be swell if someone could just compile picospan on
nextgrex and have done with it. Unfortunately, it's just not that
easy.
As far as mail goes, I'd love to put mail on another machine, and just
use lmtp to deliver locally. Unfortunately, I don't know that's going
to be practical.
|
gelinas
|
|
response 504 of 547:
|
Oct 26 04:11 UTC 2003 |
What's the big deal with Picospan? From what I've heard, Marcus has control
of the source. He can put it where he wants. Switching now doesn't gain us
anything.
|
cross
|
|
response 505 of 547:
|
Oct 26 04:57 UTC 2003 |
Maybe my understanding is flawed. It's that we don't really have a legal
license for it, Marcus sort of has a copy of the source as an artifact, and
the legalities of it all are really rather fuzzy, and he doesn't have much
control over the source at all. If the source could be opened up, all of
my objections would evaoprate, but it really seems rather more complex than
that.
|
remmers
|
|
response 506 of 547:
|
Oct 26 15:02 UTC 2003 |
Re #495 - Intel vs. Sun. Marcus and STeve are in favor of moving from
Sun to Intel hardware. In fact, at the meeting where we decided on what
type of hardware to purchase, STeve made that recommendation, speaking
for himself and Marcus. Subsequent to that, STeve was actively involved
in the hardware acquisition process.
If I had to speculate on the reasons for slow progress - the fact is
that several key staff members had unexpected situations come up in
their lives that limited the time they had available to work on
NextGrex. I think everyone on staff is committed to getting the
work done and is making an honest effort to do so within the
time constraints they have to deal with.
|
cmcgee
|
|
response 507 of 547:
|
Oct 26 15:24 UTC 2003 |
People who have been with Grex a long time may also be unconsciously comparing
"how long it took to do X" when staff was much younger, had fewer family
members living with them, and had jobs that were less consuming.
|
cross
|
|
response 508 of 547:
|
Oct 26 19:08 UTC 2003 |
Regarding #506; I think the thing that's upsetting some folks, and
perhaps rightfully so, is this idea that there are some staff members
who are `key' at all. In reality, that's the way it's always going
to be, but that doesn't mean the rest of us should be paralized by
it.
|
remmers
|
|
response 509 of 547:
|
Oct 26 19:26 UTC 2003 |
Right. But I don't think that's what's been holding things up.
|
cross
|
|
response 510 of 547:
|
Oct 26 21:08 UTC 2003 |
I concur. I just wanted to attempt to clarify.
|
jep
|
|
response 511 of 547:
|
Oct 26 22:00 UTC 2003 |
A lot of things happen behind the scenes, where most of us don't know
anything about them. When it looks like nothing is happening, that
can be frustrating. We all had a lot of expectations, I think, and
everyone cheerfully donated all the money that was asked for... then
nothing visible happened for months. That's fine, but I don't feel
guilty for asking some questions now.
So, there was a staff meeting on Saturday... was there any buy-in to
Dan's idea of moving ahead?
|
bhoward
|
|
response 512 of 547:
|
Oct 28 04:07 UTC 2003 |
Keep an eye on your mailbox, folks. My OpenBSD 3.4 CD (and t-shirt)
just arrived 30 minutes ago. Grex's ought to be arriving any day
now.
|
gelinas
|
|
response 513 of 547:
|
Oct 28 04:39 UTC 2003 |
John, the staff meeting was on Wednesday, October 22. The staff report in
the minutes of tonight's BoD meeting pretty much sums up the discussion.
The Next Step is installing OpenBSD 3.4.
|
jep
|
|
response 514 of 547:
|
Nov 9 20:09 UTC 2003 |
The question was asked in general, has OpenBSD 3.4 been installed?
|
gelinas
|
|
response 515 of 547:
|
Nov 10 00:40 UTC 2003 |
Not last I checked.
|
bhoward
|
|
response 516 of 547:
|
Nov 10 01:20 UTC 2003 |
I understand from the earlier discussion that Jan and the other staff
configuring grex have been documenting the configuration in detail.
For folks like myself curious about the technical nitty-gritty, is any
of that documention publicly available yet?
|
janc
|
|
response 517 of 547:
|
Dec 19 02:53 UTC 2003 |
I haven't read all of what's above.
I should have a lighter work-load over the holidays, but the kids won't be
in school as much, so I might not have all that much time to work on Grex
either. Still, I expect to be able to do some work.
Last night I started work on upgrading to OpenBSD 3.4. It's up and working,
and I am about half way through the business of following the instructions
to redo the installs and configuration changes that had already been
documented. As I've been working, I've also been updating and clarifying
the install documents.
Mostly the install documents have worked fine. It's not just documentation.
A lot of it is custom scripts. So setting up the /suidbin partition, moving
appropriate suid files to it and replacing the old copies with symbolic links
took about 7 minutes. Full install and setup of party took four commands and
four minutes (most of the time to ftp the source over). Configuring Apache
and the external authenticator took about 4 minutes too. There are still
some glitches - my scripts to install Orville-Write seem to have failed.
However, the goal is to be able to build a new Grex in fairly short order,
and we've made good progress toward that.
I don't have a good way to make these documents public right now. It's
nothing amazingly interesting.
One bit of good news - I've done lots of reboots as I installed stuff, rebuilt
kernels, and such. So far the ethernet interface has initialized correctly
every time. I don't know if the ethernet driver got fixed in the 3.4 release,
or if my new router just plays better with OpenBSD, but it looks like this
issue is solved.
Right now I'm just playing catch-up to get the system back to where it was
before we upgraded to 3.4. I hope to get a substantial amount of forward
progress done over the holidays. I hope other staff members will too.
|
cross
|
|
response 518 of 547:
|
Dec 19 04:02 UTC 2003 |
Great! Okay, how about relocating the machine to the pumpkin?
|
janc
|
|
response 519 of 547:
|
Dec 20 01:39 UTC 2003 |
For the next few weeks, I'll likely have some time to work on the thing.
I don't know what advantage moving it to the pumpkin would have, at least
during that time period. However, if there is any strength of opinion
favoring that, I'd actually love to have it off my desk. It's fans are
loud and it takes up scarce desk space.
|
cross
|
|
response 520 of 547:
|
Dec 20 03:42 UTC 2003 |
If it's coming up on the network reliably now, the advantage is that
(a) we an test out network services other than those that you poke holes
in your firewall for, and (b) it's closer to oldgrex, and (c) it's already
in place for when grex shifts to it.
|
gelinas
|
|
response 521 of 547:
|
Dec 20 04:08 UTC 2003 |
All good reasons, but I'd like to see it a bit closer to being ready for use
before moving it. I'd like to see it move early in January, earlier if
possible.
|
mary
|
|
response 522 of 547:
|
Dec 20 13:15 UTC 2003 |
Thanks, Jan.
|
janc
|
|
response 523 of 547:
|
Dec 21 17:43 UTC 2003 |
Actually being able to make it accessible via http and smtp and things like
that may be useful for testing. Well, for other people. I can access those
services just fine :).
I'll move it as soon as any staff member says they'd find it easier to do
their work if it was moved, or at the end of the first week of January, at
which point I'm booting it out my house no matter what state it is in.
|
cross
|
|
response 524 of 547:
|
Dec 21 19:58 UTC 2003 |
I think it'd be a lot easier to set up a decent mail configuration if it were
moved earlier.
|
