Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Unix Recovery Legend (1986)

ee.ryerson.ca

Post reply on HN
Print view View original

41–50 of 63 posts

Re: Unix Recovery Legend (1986)

#41

Post by Spooky23 »

krylon wrote: post #11

> Well, for one thing, you must always remember the immortal words, DON'T PANIC So true. A colleague of mine managed - on his second or third day on job - to delete every single user account in our Active Directory. After an hour, we gave up trying to restore the AD (it was an SBS2008, so no AD recycle bin) and simply restored the entire DC (at the time, our domain only had the one DC) from backup. Surprisingly, most…

Amen. I was a new DBA at a company that used a DBMS which used extent based disk allocation with a default extent size of 16kb. That was a problem on a busy table (which this was), because there was a finite limit to the number of extents that could allocated, but that limit was impossible to predict.

The proactive fix was simple. Backup, restore the table in a two hour outage window. I asked for 5 hours, as the previous DBA never tested a restore. "Unacceptable", said the SVP.

Fast forward two weeks. We hit the limit, and the entire company is essentially down. Between lost revenue, SLA fines and payroll, they were losing something like $5k/minute. Recovery at this point required 30 hours of full database restore, including journal recoveries from slooooow DAT tapes.

There were three of us, everyone stayed calm, provided regular updates and handled a few hours of direct observation by the CEO and a board member for a few hours.

Re: Unix Recovery Legend (1986)

#43

Post by cremno »

pki wrote: post #39

Slightly off-topic but I am curious: what are the things at the bottom? Are they precursors to email or something?

Somewhat. Those are/were actual email addresses. It's just another kind of email (UUCP/Usenet instead of SMTP):

https://en.wikipedia.org/wiki/UUCP#Mail_routing

Re: Unix Recovery Legend (1986)

#44

Post by rwh86 »

pki wrote: post #39

Slightly off-topic but I am curious: what are the things at the bottom? Are they precursors to email or something?

By "things" I assume you mean this stuff:

> ARPA: miw%uk.ac.man.cs.ux@cs.ucl.ac.uk > USENET: mcvax!ukc!man.cs.ux!miw > JANET: miw@uk.ac.man.cs.ux

miw is clearly Mario Wolczko's username.

Those will be his email address in different formats. The first would route email to him at miw@uk.ac.man.cs.ux using cs.ucl.ac.uk first as a gateway. The second address format is what's called a bang path, for UUCP email. The final one is a modern IETF standard email address. JANET is a network provider for UK academic institutions, similar to an ISP but structured differently.

You might find these references interesting:

https://en.wikipedia.org/wiki/Email_address http://www.faqs.org/docs/linux_network/x-087-2-mail.address.... http://www.livinginternet.com/e/ew_addr.htm

Re: Unix Recovery Legend (1986)

#45

Post by wsterling »

charonn0 wrote: post #36
wsterling wrote: post #33

Why did they not boot from installation/recovery media, mount the drive, copy what was left, restore and copy back the user and configuration data that was found?

> Alternatively, we could get the boot tape out and rebuild the root filesystem, but neither James nor Neil had done that before, and we weren't sure that the first thing to happen would be that the whole disk would be re-formatted, losing all our user files. (We take dumps of the user files every Thursday; by Murphy's Law this had to happen on a Wednesday). Another solution might be to borrow a disk from another VAX…

Yea, I am not buying it. They have a UNIX guru that is building new commands in assembly and transferring the files with uuencoding but no one knows how a recovery tape works? Using a recovery tape was not a rare event in UNIX shops.

Re: Unix Recovery Legend (1986)

#46

Post by JoshTriplett »

TheLoneWolfling wrote: post #23
pdw wrote: post #21

Earlier quoted context omitted.

This particular variation was (finally!) fixed in the 2013 POSIX revision: "If either of the files dot or dot-dot are specified as the basename portion of an operand (that is, the final pathname component) or if an operand resolves to the root directory, rm shall write a diagnostic message to standard error and do nothing more with such operands." http://pubs.opengroup.org/onlinepubs/9699919799/utilities/rm... Warnin…

Personally, I wish two things: 1) that rm had a (configurable) number of files / directories above which it'll ask you to double-check. 2) that files had a "pleasedontdelete" flag that rm would check and ask about.

> 1) that rm had a (configurable) number of files / directories above which it'll ask you to double-check.

Install safe-rm; it does exactly that.

Re: Unix Recovery Legend (1986)

#47

Post by kjs3 »

I remember the before-time, when the GNU lived only in Boston. When beasts like 'adb' and 'fsdb' roamed the earth, and 'fsck' was the wimpy stuff of childrens taunts. When I controlled my horror and revulsion and used them to recover the broken VAX by manually rebuilding inode lists and finding the lost fragments in the dark.

Hard tools for hard admins; the Gods of BSD, McKusick and Joy and the rest, were and are wise. We live in more refined times....

Re: Unix Recovery Legend (1986)

#48

Post by JoshTriplett »

duaneb wrote: post #5
GTP wrote: post #4

Earlier quoted context omitted.

Why is impossible? Maybe I've understood why it is always built in: without it the shell wouldn't be able to navigate through the directory tree to find the executables of the commands. But once the shell has it, I think it would be rendundant (so nobody does it) but still possible to have a /bin/cd that navigates directories.

You can't change the environment of the parent process, including CWD. `/bin/cd` would either be another process like all executables run by the shell, and not work, or special cased, at which point why make it an executable at all?

I can think of one way to write "cd" out-of-process from the shell: exec /bin/cd /some/path, which does chdir("/some/path") and execs your shell. You'd lose your history and similar state, but if you had a shell that didn't even put cd in-process, it probably doesn't have history either.

Sample:

    /tmp$ exec /tmp/cd /bin
    /bin$ exec /tmp/cd /home
    /home$ exec /tmp/cd /usr
    /usr$
Sample code:

    #include 
    #include 
    #include 
    
    int main(int argc, char *argv[])
    {
        char *shell;
        if (argc != 2)
            errx(1, "Usage: exec cd /some/path");
        if (chdir(argv[1]) == -1)
            err(1, "chdir");
        shell = getenv("SHELL");
        if (!shell || !*shell)
            shell = "/bin/sh";
        execl(shell, shell, NULL);
        err(1, "exec");
    }

Re: Unix Recovery Legend (1986)

#49

Post by duaneb »

JoshTriplett wrote: post #48
duaneb wrote: post #5

Earlier quoted context omitted.

You can't change the environment of the parent process, including CWD. `/bin/cd` would either be another process like all executables run by the shell, and not work, or special cased, at which point why make it an executable at all?

I can think of one way to write "cd" out-of-process from the shell: exec /bin/cd /some/path, which does chdir("/some/path") and execs your shell. You'd lose your history and similar state, but if you had a shell that didn't even put cd in-process, it probably doesn't have history either. Sample: /tmp$ exec /tmp/cd /bin /bin$ exec /tmp/cd /home /home$ exec /tmp/cd /usr /usr$ Sample code: #include #include #include int…

Hah, hadn't thought of that. Kind of CPS for processes. I'm not sure what that would gain you, though, as you'd have to either a) write both the cd and the user of the cd, and there are less awkward ways to do that than exec'ing, or b) you'd have to pass something ELSE to exec to return control after cd finishes.

This seems a little awkward and I'm not sure what is being proven. :P

Re: Unix Recovery Legend (1986)

#50

Post by pm215 »

rwh86 wrote: post #44
pki wrote: post #39

Slightly off-topic but I am curious: what are the things at the bottom? Are they precursors to email or something?

By "things" I assume you mean this stuff: > ARPA: miw%uk.ac.man.cs.ux@cs.ucl.ac.uk > USENET: mcvax!ukc!man.cs.ux!miw > JANET: miw@uk.ac.man.cs.ux miw is clearly Mario Wolczko's username. Those will be his email address in different formats. The first would route email to him at miw@uk.ac.man.cs.ux using cs.ucl.ac.uk first as a gateway. The second address format is what's called a bang path, for UUCP email. The final…

I think that last one isn't a modern standard email address -- the domain part is reversed. It's a JANET NRS path (https://en.m.wikipedia.org/wiki/JANET_NRS). The modern equivalent would be miw@ux.cs.man.ac.uk.

The first email address (the ARPA one) is presumably using a machine in UCL as the gateway between internet routing and JANET routing, since the part before the % is the JANET NRS component ordering. The obvious conclusion would be that the mail server he was using didn't have an ARPAnet connection at all.

Post reply on HN