| Grex > Coop12 > #176: Next Grex Hardware |  |
| response 435 of 547: | 
Oct 17 17:23 UTC 2003 |
It's stalled; too many staff have too many other things going on. I was
going to propose, and I suppose here is as good a place to do it, that
we move nextgrex from Jan's house to the pumpkin after the new version
of OpenBSD comes out. I think that'll make it easier to test and debug
subsystems, and ultimately easier to transition over from old grex to
new grex. Once we do that, we should set a schedule; a reasonable one,
that we can stick to, trying to anticipate people's time demands, for
switching over within, say, no more than three months.
Major subsystems I see needing configuration before we can switch are:
1) The BBS. Someone has to port PicoSpan (mdw?) or provide
an alternative (YAPP? Frontalk?)
2) Mail. We have to build out the mail system.
3) set up newuser
4) Configuration changes.
That's about it. Everything else, we can do once we've transitioned.
| response 436 of 547: |
Oct 17 17:30 UTC 2003 |
I'd say that's a fair summary. Only potential drawback that I can see to locating it in the pumpkin is if the hardware still needs a fair amount of hands-on attention, it'd be a nuisance for somebody to run over there all the time to tend to it. If the hardware configuration is pretty stable now, this isn't an issue.
| response 437 of 547: |
Oct 17 17:47 UTC 2003 |
This response has been erased.
| response 438 of 547: |
Oct 17 18:09 UTC 2003 |
Could we keep mail as is, on old Grex, for a while? Maybe get it up using YAPP and Frontalk only? I, like everyone else, would hat to see this project stagnate much longer. If that means coming up less complete, that would be better than not at all.
| response 439 of 547: |
Oct 17 19:20 UTC 2003 |
I agree. Re #437: My understanding is that Grex is running a legal copy of Picospan, though we do not have an official license. The validity of our copy comes from Marcus, so he needs to explain how that works.
| response 440 of 547: |
Oct 17 19:58 UTC 2003 |
Sorry for the sharp-sounding comment at the end of my question. It didn't come out the way I had imagined it would. No criticism was intended. If the hardware is moved to the Pumpkin, are there people who can do the things which need doing? Is the direction of the mail system determined closely enough that another staffer can do it, or is this a "Marcus-only" project? How about newuser? I assume Picospan is something only Marcus can do. I'd hope the staff is avoiding things wherever possible that can only be done by one specific person, whether it's Marcus or anyone else. Specifically... all of the world uses e-mail; Grex should be able to implement an e-mail system, too. It isn't even that important. If Grex didn't have e-mail at all, every Grexer would be able to get by anyway by using any of their dozens of other mail addresses. It would be silly to find out NextGrex was being held up only because a specific person wasn't available to set up a customized e-mail system. For other topics; is there agreement on what needs to be done for newuser? Is someone working on that? I'm not particularly parsimonious... but all of the hardware was purchased months ago, some of it at premium prices as I understand it to obtain stuff that's state of the art. Computer hardware doesn't have much of a shelf life for being state of the art. Grex got donations, and bought all of the stuff at a pretty quick pace... then nothing much seems to have happened, at least judging from the information I'm seeing coming out. It made me wonder about why things aren't happening any more. Is it a brief slowdown for specific reasons, and things will be picking up again soon? Thanks!
| response 441 of 547: |
Oct 17 20:02 UTC 2003 |
This response has been erased.
| response 442 of 547: |
Oct 18 00:39 UTC 2003 |
Re 440: John, some users have no other email address whatsoever. I happen to live with 3 of them. Other users have enough correspondents who email to their Grex addresses that notifying them all would be a big problem - and suddenly having mail start bouncing without much warning would be a much bigger problem. I'd say we could do without conferencing for a while about as well as doing without email.
| response 443 of 547: |
Oct 18 02:05 UTC 2003 |
Regarding #440; We're not going live without a working mail system. It's not rocket science to put one together, but it does take time, and that's what everyone is lacking right now. Regarding Remmers's comment about hardware configuration; As far as I can tell, with the exception of the ethernet interface (which seems flakey), it's pretty much set. Everything left is purely software configuration.
| response 444 of 547: |
Oct 18 03:18 UTC 2003 |
I'll accept the point about e-mail, but that's not the main point. resp:0 brings up the idea of buying the hardware right away... February 17, 2003. There was enthusiasm at that time, maybe even some urgency. The first component was purchased on April 8, ordering continued through April, assembly began on May 4, and by May 17, aruba said it was all assembled, tested and working. There was enthusiastic testing through May. The final physical component arrived on May 28 -- the OpenBSD CDs. And work stopped, at least as visible to interested outsiders. It has been 4 1/2 months since May 28; approximately twice as long as it took to acquire, assemble and test all of the hardware. I presume OpenBSD has been installed on the new hardware so that *something* can have been done since then. In 4 1/2 more months, it will have been a year since this item was entered. Where's the urgency now? Or at least enthusiasm? Shall I wait until February and ask again then? Or maybe hold my horses until April? Or will that have been too soon to expect results from the purchase of all new hardware that was fully assembled by the end of May? If we hadn't bought anything yet, how much further behind would we be, compared to where we are now? Put another way, how long do we wait before the hardware needs to be replaced because it's too old? I understand very well about being too busy... I also understand it's not always *everyone* who's too busy. That's not even very likely. There have been many group projects that never happen at all because everyone waits forever on one person. It would be a real shame if this project is one like that. The treasurer bemoans the lack of donations all the time. Donations are declining... but a lot of people rushed right in to send money when they were told it was needed for the new NextGrex computer. You folks on the staff gave every indication you were ready to set it up so we could start using it. We all understood it would take time... but how much time? It takes a *really* *long* time to finish a project if no one is working on it. If that's the case, as it appears to me it is, maybe it it could be time to look at alternatives?
| response 445 of 547: |
Oct 18 04:49 UTC 2003 |
Hey, I agree with you 100%. It's ridiculous that it's taken this long to get things rolling. I think we should be able to move over to next grex within three months, and I can think of no reason we shouldn't be able to: this has stalled long enough. There is some work happening, but you won't see it if you just read coop. Most of it happens in garage, and some (to a much lesser extent) in other places. In particular, despite juggling kids and other time commitments, Jan has made some stellar progress setting up facets of nextgrex. Regardless, we're stalled right now. Here's my take on some of what happened. There's been disagreement among staff about how _best_ to proceed in certain technical areas. But traditionally, certain staff members have maintained domains of responsibility comprising various subsystems on grex (like how Marcus maintains PicoSpan). Some of this is necessary (Marcus and PicoSpan is a good example; he's the only one with the source code), some is contrived. Those parts have been, if not off-limits to other staffers, then at least considered that individual staffer's responsibility and left up to them. So, despite some staffers having more time than others, certain areas of nextgrex remain untouched pending the staffers who have less time, but traditional responsibility of those areas, to become available. I don't think this is working out too well. I think maybe we should consider just saying, ``screw it; we need to get the new machine online. Let's figure out the quickest way to do that and go from there.'' *THAT* said, we also have to be careful. Grex, right now, is a real mess in my opinion. There are patches upon patches upon bandaids upon kludges upon hacks upon more patches stacked up so high, it's difficult to see over them all. I think it's scary for newer staff (well, for me anyway) to *do* anything because everything is so customized. A lot of the work Jan has been doing on nextgrex is meticulously documenting *everything* he's done so that rebuilding grex from scratch is going to be an easy process for a reasonably competent Unix system administrator. This is good, and necessary, and we really do need to do this with all the major components of the system so that, moving forward, we don't end up in the hole we're in right now (it really is a hole). I think we can get back on track if a couple of us agree to donate a few hours or so a day for the next couple of weeks, to get OpenBSD 3.4 to where we're at now with OpenBSD 3.3 (note: OpenBSD 3.4 comes out on the first of November). If we then put the machine in the pumpkin, we should be good to go with getting nextgrex online in under three months. hour or so a day for the next few weeks to g
| response 446 of 547: |
Oct 18 14:27 UTC 2003 |
This response has been erased.
| response 447 of 547: |
Oct 18 14:46 UTC 2003 |
I've proved the security of grex's password hash to be the same as that of sha1, which is provably mathematically superior to MD5. Also, isn't YAPP shareware? I thought you had to pay a significant amount of money for anything other than casual use?
| response 448 of 547: |
Oct 18 15:12 UTC 2003 |
This response has been erased.
| response 449 of 547: |
Oct 18 19:06 UTC 2003 |
Blowfish in OpenBSD is pretty slow. I've argued many times that building our own scrambling algorithm was a bad idea, and I certainly would have done it differently, but it happened before I came on board. Sorry, them's the breaks. Sometimes you just have to accept what you're given and work with it as best you can: we've got anywhere from 20,000 to 40,000 users whose passwords are hashed with it. But, we've also gotten it working with OpenBSD (I've got it working with login.conf on nextgrex). Jamie, I think you have a lot of good ideas on how to move grex forward, but don't blow it by being your polemical self. Three months *is* a reasonable amount of time for a complete build out of nextgrex. And I don't care how long it took Salcedo to get mnet up and running. This isn't mnet, and we want to have an amount of downtown that's a minimal amount longer than the time it takes to transfer the data from oldgrex to nextgrex (five weeks just to move things over---now that's outrageously long, in my opinion). I don't even live anywhere *near* Ann Arbor (otherwise, I'd volunteer to take in the hardware and crank away on it over the next two or three weekends), and other staffers don't have a lot of time, so it's unlikely we'll be able to half the amount of time I already projected. As for YAPP, I'm all for it. We need something up and running sooner than later. However, ``you-think-you-heard-someone-say-maybe'' isn't a license agreement, and if your primary objection to PicoSpan is a licensing issue, then trading that can of worms for a mess that is a verbal licensing agreement for YAPP doesn't seem much better. Now, if I had my druthers, I'd just as soon see FrontTalk built out and used as a replacement for both. We're sure of the license for that; unfortunately, that would require someone talking a lot of time to make happen, and, as we know, time is an issue. Look, you're preaching to the choir here. So cut the confrontational crap and let's figure out how to move forward.
| response 450 of 547: |
Oct 18 19:16 UTC 2003 |
This response has been erased.
| response 451 of 547: |
Oct 18 20:19 UTC 2003 |
I would like to see us stay with picospan. I left m-net when they switched to yapp. I tried it for a couple of weeks, hated it and never logged in again.
| response 452 of 547: |
Oct 18 20:29 UTC 2003 |
This response has been erased.
| response 453 of 547: |
Oct 18 20:39 UTC 2003 |
This response has been erased.
| response 454 of 547: |
Oct 18 21:02 UTC 2003 |
Four and a half months is long enough to wait for one or two formerly essential people to do what they have apparently promised. If there are holdups who aren't going to do what Grex needs, then they need to be replaced. Otherwise, the future of Grex is being held hostage, and those one or two people are being treated as more important than all of the rest of us.
I can understand it if no one on the staff wants to state it that baldly. There seems to be little enough of teamwork for this project. So there it is, I'll say it.
I have used YAPP for years, and Picospan for years, btw, and have not noticed any deficiencies in text YAPP. (WebYAPP is horrible, but Backtalk is available.) Let's put it this way, I'd rather have YAPP and NextGrex than Picospan and the rotting remains of obsolete Sun hardware.
| response 455 of 547: |
Oct 18 21:35 UTC 2003 |
Regarding #450; You're making all the same arguments I did. They haven't worked yet, but I'm willing to transition to another algorithm. It just takes convincing people that it's the right thing to do. However, the specific suggestion you make, to use the password expiration feature to force switching to another algorithm, would take a year (and is also something I suggested several years ago). Regarding #451; What specifically didn't you like about it? To me, they seem functionally equivalent, though I confess to not using any of the more exotic features of either. Regarding #454; Okay, that's fair. Btw- it's not just picospan; there are a number of things that are waiting the laying on of hands of one or two people. I confess I myself am guilty of stalling on at least one thing. The way I look at it today, it's silly to try and do anything before OpenBSD 3.4 comes out on the first of November. Assuming there's going to be a bit of rough edges around the release, let's say it's reasonable to assume we can do an FTP install on the 4th or so. From today, that gives us about three weeks before we can *really* make any software changes. I propose this: we start the clock for the transition to nextgrex today. We have the period between now and the 4th of November to argue about how to do things, and then once November hits, we have two months and one week to get the new system online, with all of the data transferred, and the Sun turned off. I feel pretty confident we could make that deadline, and if someone has a pet project they can't squeeze in before that, too bad. Comments?
| response 456 of 547: |
Oct 18 21:51 UTC 2003 |
Regarding #448; By the way, the details of the grex password hash, as well as the details about the configuration of many of the subsystems on grex, have been publically available for some time through the, ``grex staff notes'' on the web. Indeed, there's even a link to the code that implements it (using that was how I ported it to nextgrex). See http://www.cyberspace.org/staffnote/passwd.html, with the actual code at: http://www.cyberspace.org/staffnote/mkp2.c.
| response 457 of 547: |
Oct 19 00:09 UTC 2003 |
This response has been erased.
| response 458 of 547: |
Oct 19 03:06 UTC 2003 |
Responding to #457: (1) No. It has it's own recognizable token that doesn't match $[0-9]+$, but it's easy enough to switch off. /etc/master.passwd can be put together with awk or perl. Indeed, I already have a script to do it, and authentication uses the standard BSD login.conf framework. There are two possible places to go from here. (a) we move to Kerberos. This could be done by modifying the password changing program to automatically register principles using a standard string to key algorithm, or by using the modified KDC Marcus wants that uses his hash algorithm, where we'd use the existing contents of /etc/shadow as the key database. I think the latter is a really bad idea. (b) keep the same hash algorithm, using the login.conf framework to deal with it. Okay, there are really three: (c) switch over to one of the system standard algorithms after a suitable period of time, by modifying the password changing program to do it. Our customizations would disappear after a year or so. I favor this route. If we want to go Kerberos, it'd be best to go with a standard string to key algorithm, but this would be easy using methods I've already outlined elsewhere, using login.conf to make them transparant to the user. (2) That's the equivalent of a site-dependent salt. The idea is that if the same algorithm is used on more than one site, the hashes shouldn't come out to be the same. (3) That's not even the case with conventional cryptography (the algorithm doesn't get *easier* to crack, it just doesn't get appreciably harder). Regardless, this isn't conventional cryptography; it's a compression based hash algorithm. Marcus's password scrambling algorithm is essentially the HMAC construction applied to password hashing. The thing is, HMAC doesn't provide any additional security to password hashing over simple hashing, because it's designed to solve a different problem: authenticating messages over an insecure network, using a shared secret key. The thing is, with password hashing, either the key or the message is fixed, so you don't get any additional security. (4) That would require a change in the current configuration. But, there's no point. We have the situation with the password hashing algorithm well in hand on nextgrex. See (1). Don't bother arguing about the custom hash algorithm. It was a mistake (well, sort of. It was better than Unix crypt(3)); everyone knows that.
| response 459 of 547: |
Oct 19 03:28 UTC 2003 |
What reason is there to believe that anything will start on November 4, when it didn't start on May 28? Dan, are you speaking for the staff?