|
|
| Author |
Message |
| 25 new of 547 responses total. |
spooked
|
|
response 252 of 547:
| 
May 16 01:24 UTC 2003 |
*smiles* We guard it by BIG nasty dogs - they won't get too far :)
|
gelinas
|
|
response 253 of 547:
|
May 16 02:17 UTC 2003 |
Dan, yes, even if the disks were scrubbed first.
I know folks with lots of spare time on their hands. I know folks
who have written their own disk-recovery software. (To the best of my
knowledge, the intersection of those two sets, BTW, is the null set.)
I can see someone with the time and interest using the grex disks as an
experiment base for their own efforts. (They'd probably settle for *any*
disk, not just grex's.)
|
lk
|
|
response 254 of 547:
|
May 16 04:30 UTC 2003 |
Who's in charge of offing people who find out the address of the Pumpkin?
Mark, don't freak out, but I have your address. See that car parked
outside your house? The dark van, with the tinted windows? That's my
sister. She's Mossad so you might not be able to spot the van. Nonetheless,
since you have the new disks, it's only a matter of time before you deliver
them either to the Pumpkin or to someone else who will ultimately take them
there. Don't look over your back, she's following you. Take my word for it.
And then, when we discover the location of the pumpkin, we'll contact
G Gordon Liddy to break in and steal the tapes. Er, disks....
Actually, I got a good laugh from Walter's comment:
> it's reasonable to assume that any data on grex worthy of such
> efforts has already been stolen
So we're just discussing how wide to leave open the barn doors. (:
(Though obviously, some horses are still inside.)
|
aruba
|
|
response 255 of 547:
|
May 16 13:12 UTC 2003 |
So *that's* why that woman was following me yesterday.
|
jhudson
|
|
response 256 of 547:
|
May 16 15:46 UTC 2003 |
What's the matter guys, can't figure out how I know the address
even though I am ~2000 miles away.
|
tod
|
|
response 257 of 547:
|
May 16 16:16 UTC 2003 |
This response has been erased.
|
cross
|
|
response 258 of 547:
|
May 16 16:34 UTC 2003 |
It depends on whether Leeron's sister is smoking or not. Leeron,
got a picture? Nyuk nyuk nyuk. Beware those Israeli women, though;
though they smoke, they're heart breakers.
Regarding #253; Joe, if you know someone who can recover data from a
properly scrubbed disk, I'd almost be willing to say, give them the
disks and see if they can get anything off of them.
|
lk
|
|
response 259 of 547:
|
May 16 17:13 UTC 2003 |
My dad wouldn't let us drink colored food items in the 1960s, long
before the FDA would ban them. So despite all those bad influences
outside the house, none of the kids smoke and we all detest it.
As a child, when I was offered a puff (by an "uncle" who since died
of emphezyma), I exhaled to make the tip glow (every 8-year old is
a pyro). Like Clinton (or not), in never occured to me that I was
supposed to inhale and ingest the smoke....
To this day I tell my clients that, if they love their computers,
they shouldn't smoke around them.
Which brings us back to the subject (whew!). Instead of scrubbing
the computers clean, can't se smoke them dirty?
|
aruba
|
|
response 260 of 547:
|
May 16 17:37 UTC 2003 |
I installed the SCSI disks today - the controller and fdisk recognized them
right away, with no problems. I'm running surface scans now.
|
jhudson
|
|
response 261 of 547:
|
May 16 18:36 UTC 2003 |
good, can't beat w98 scandisk for that (though why I don't know)
|
gull
|
|
response 262 of 547:
|
May 17 00:35 UTC 2003 |
Re #253: I've written disk recovery software, too, for retrieving
*deleted* stuff. But that's different than recovering data from a disk
that's been wiped, because the electronics in the drive are unable to
read the data at that point. Recovery is then a matter of removing the
platters in a clean room environment and using sophisticated equipment
to analyze the magnetic patterns left on them. I *seriously* doubt
anyone is going to go to that expense with a home disk from Grex so they
can read a bunch of archived spam mail and obsolete copies of eggdrop. ;)
|
aruba
|
|
response 263 of 547:
|
May 17 00:43 UTC 2003 |
I ran surface scans of all four of our disks (3 SCSI and one IDE), and there
were no bad sectors on any of them.
|
gull
|
|
response 264 of 547:
|
May 17 01:15 UTC 2003 |
Good deal.
I haven't found bad sectors on a new disk in a long time. Modern drives
have "spare" sectors they remap to hide bad ones, so by the time you
start seeing bad sectors on a disk it's already pretty sick, and
probably has been getting worse for quite a while.
|
janc
|
|
response 265 of 547:
|
May 17 01:42 UTC 2003 |
Excellent, Mark.
|
cross
|
|
response 266 of 547:
|
May 17 05:27 UTC 2003 |
Hooray! So am I correct in understanding that all the hardware has
now been acquired and installed, and we're ready to go with configuring
NextGrex?
|
aruba
|
|
response 267 of 547:
|
May 17 21:18 UTC 2003 |
Yup, that's correct. All the hardware is in one box, and everything works.
|
cross
|
|
response 268 of 547:
|
May 17 21:46 UTC 2003 |
Excellent.... Eeexxxccellet. Proceed with the next phase of
the...operation...number two.
|
aruba
|
|
response 269 of 547:
|
May 17 22:16 UTC 2003 |
BTW, I know we don't need them, but it looks like our OpenBSD CDs shipped
last Tuesday. At least our credit card was charged then - I haven't
received a confirmation email.
|
valerie
|
|
response 270 of 547:
|
May 18 22:41 UTC 2003 |
This response has been erased.
|
jep
|
|
response 271 of 547:
|
May 19 03:04 UTC 2003 |
re the responses to resp:246: I'm not going to embarrass anyone by
posting the messages I got in response to my e-mail to staff, and I
think some were humorously intended anyway. It took me 18 minutes to
get an e-mailed response with the address of Grex.
I was asked to not post the address. With all due respect, I think
it's not a meaningful request. However, I do have a lot of respect
for the Grex staff and since they asked, I won't post it.
Certainly, anyone wishing to obtain anything from Grex could do so
much more easily and certainly than by trying to recover data from a
formatted hard disk. Eric's concerns were well-intended but not a
realistic concern.
If anyone really wants anything from the old Grex hard disks, enough
to use data recovery techniques, Grex might entertain competitive
bids. If they gave Grex half the money they'd otherwise have to
spend, there would never again be a financial crisis. The staff could
be paid, the Board could be paid, and if I were given an appropriate
commission for coming up with the idea, I would never have another
financial concern.
|
cross
|
|
response 272 of 547:
|
May 19 04:16 UTC 2003 |
Yeah, true. Also, Joe earlier posted some odds for getting data off
of a scrubbed disk. He made it clear he was doing so without real
data, but I want to get those numbers closer to reality; he said
something like 15% odds of getting something good for a casual attacker,
30% for a determined attacker. However, in both cases, the attacker
isn't expending a lot of financial resources; only time and clevernes.
No access to fancy clean-rooms or the like. In that case, I'd give
a casual attacker something like 0.00001%, and a determined attacker
something like 0.0001%. Note that determination gives you an order
of magnitude advantage.
Those numbers are probably conservative; real numbers are probably
a lot closer to zero.
|
janc
|
|
response 273 of 547:
|
May 19 04:38 UTC 2003 |
Well, we had another Next Grex Meeting, somewhat sparsely attended - Mark
Conger, Joe Gelinas, John Remmers, Valerie Mates, Jan Wolter. Steves Weiss
and Andre' called to say they couldn't make it. Mark brought along the Next
Grex, which we set up temporarily and tried booting off an OpenBSD boot floppy
that John had brought along. Mostly looked good, but although it found the
SCSI controller, it did not find the SCSI drives. So we went about the proper
businesses of sitting around and talking about the computer.
After everyone left, I moved the machine down to my office, where it can be
plugged into the LAN and tried various things. Second thing I tried was one
of the other OpenBSD boot floppies. There are three in the distribution.
One for standard systems, one with extra drivers for SCSI and raid and gigabit
ethernet, one for laptops. John's was the second one, the one with SCSI
stuff. I tried the standard one, floppy33.fs, and that found the SCSI drives
without a problem.
I have volunteered to take a first cut at partitioning the drives and
installing OpenBSD. When I've done that, I'll get it on my LAN, open an
SSH portal to in through my firewall, and advertize it to staff.
I'm currently scratching my head of partitioning options, having had somewhat
less input from others than I would like, but I'll do something plausible.
If it stinks, we'll redo it.
|
aruba
|
|
response 274 of 547:
|
May 19 04:44 UTC 2003 |
Thanks Jan - enjoy those seven fans. :)
|
cross
|
|
response 275 of 547:
|
May 19 05:56 UTC 2003 |
Suggestions regarding partitioning. This is what I would do:
(a) Use RAIDframe across all the SCSI disks. Partition them
thusly:
32MB sd[0-2]a (The second-stage bootstrap and kernel)
1024MB sd[0-2]b (Swap, striped across 3 disks)
rest sd[0-2]d (Everything else)
Set up the RAIDframe partitions on sd[0-2]d.
Use RAID-5 with an interleave size of 64KB
(the size of an FFS1 ``extent'').
(b) Configure the following filesystems. You'll have to use
disklabel, but it's not particularly hard:
512MB / raid0a
2048MB /usr raid0d
4096MB /usr/local raid0e
4096MB /var raid0f
4096MB /grex raid0g
512MB /tmp raid0h
rest /u raid0i
80GB /scratch wd0d
(Yes, OpenBSD supports disklabels with more than 8
partitions on them....)
(c) Put mail in $home/Mailbox; that does away with the need
for a seperate /var/mail partition.
(d) Merge /suidbin into /. / in 4.4BSD doesn't contain nearly
as much ``non-system'' stuff as did / in 4.3BSD and prior
versions. It's easiest to think of it as a ``system''
partition with a minimum of non-system related stuff in it;
having suid tools in /, if one restricts it to system purposes,
is just fine. In this configuration / can remain the only
partition that has suid binaries on it, and it can remain
writable. This has some advantages: (i) All the suid tools
are available in single user mode. (ii) It's writable, which
means that a bug in a suid program can be quickly corrected
by staff. (iii) It cleanly keeps all ``system'' related
files in one place.
(e) Create symbolic links from /usr/src and /usr/obj to
/var/src and /var/obj, respectively. Also, create a
/var/local hierarchy. Create symbolic links from
writable places in /usr/local to /var/local. By doing
this, you're able to (i) make both /usr and /usr/local
read-only most of the time, while (ii) retaining the
ability to keep the system sources up to date.
(f) Move the BBS and associated files into /grex; this is
the place for grex-specific software. Party, the BBS,
etc can go in there.
I'd further do the following:
(a) Split /suidbin into /suid/bin and /suid/sbin. This breaks
up functionality a bit; user-software that is used by
general users can go into /suid/bin. Sysadmin stuff goes
into /suid/sbin.
(b) Create /local; put local stuff that's useful in single user
mode in here. Ie, Kerberos, Kerberized sudo, SSH, maybe a
shell or something, etc.
(c) Remove some of the goofy symlinks from /; why is /b a symlink
to bbs?
(d) Change the startup scripts to newfs /tmp every time the
system boots.
The biggest changes here are putting more stuff in /, and doing away with
/var/mail. The latter is for security and convenience; the former is
purely for convenience.
Oh, a node on the difference between sd[0-2]a and raid0a. The OpenBSD
RAID software can get its root filesystem from raid, but cannot read the
kernel upon boot out of a RAID partition. sd0a would be a *really*
small partition, mirrored on sd1a and sd2a as well, that contains the
second-stage bootstrap and the kernel to boot from. A copy of the
exact same kernel would be in /; once the system started booting, it
would be transparent. The system can be booted off of any disk, and
the loss of any single drive wouldn't impact grex much. It could be
swapped out and the parity rebuilt while the system was operating.
|
janc
|
|
response 276 of 547:
|
May 19 12:52 UTC 2003 |
Dan - Thanks. Looks like I'm going to have to read up more on RAID.
One note of possible concern: It's not clear how well our SCSI controller
is supported by OpenBSD 3.3. We have an Adaptec 29160 controller which
apparantly stars the 7899G chipset. In the OpenBSD 3.3 file INSTALL.i386
it says the following in the list of supported hardware:
Adaptec AIC-789[29] chips and products like the
AHA-29160 based upon it which do 160MB/sec SCSI. [C]
(However, the 7899G card is currently not supported with
more than one device attached)
Well, we have more than one device on our card. Web searches show lots of
messages from people who had problems with OpenBSD and the 29160. For some
of them, using only one device on the controller worked fine. These messages
generally had followups saying that these problems were fixed in later
releases. This is a fairly popular card, and you'd expect getting it to
work would have been a priority for someone. However, as you see, they
didn't delete the note saying it didn't work with multiple devices from the
install document.
I'm guessing/hoping that this is just a reflection of their poor document
maintenance. Though the 386 install document seems to me to be the single
most important document to maintain, it seems to be fraught with errors,
mainly places where it appears not to have been updated when the software
was. In the section quoted above, for example, the [C] indicates that the
driver is not included on install floppy C. However, it appeared not to work
on install floppy B either, and there is no [B] there.
Hmm...raid support is on floppy C, our SCSI driver support is on B. Could
be an annoyance if we try to build a RAID system.
|
