Hm. Sat in a coffee shop, decided to tidy things on the laptop. By
uninstalling old kernels.
Nothing wrong in that. Just type the version number of the OLD ones, not the
kernel that's actually running...
RC
On 19 August 2011 23:41, Mark Hindess <list-hants-...@temporalanomaly.com>wrote:
>
> In message <
> cacaqtbfhsn+b1twem0fxypdx9q7uveo2rpxb+fhqkjxtd0-...@mail.gmail.com>,
> Edward Beckmann writes:
> >
> > Hi All
> >
> > As it's friday and I have just caused my longsuffering sysadmin to moan
> at
> > my stupidity yet again , I thought I would offer a challenge for amusing
> > typos or human errors. Examples could be:
> >
> > who can do the most damage to a system with the fewest number of
> keystrokes?
> >
> > what duff error gives the most spectacular failure?
> >
> > what error can trigger the longest chain of disasters?
> >
> > I am sure you get the gist ....
> >
> > Bonus marks for anyone brave / foolhardy enough to say "I did ..." as
> > opposed to "I knew someone who did ..."
>
> Excellent questions.
>
> Two things spring to mind.
>
> Firstly, when I was a {sys,net}adm in the University of Bath in the late
> '90s, I used to run regular nmap scans of the campus networks to look
> for machines with known vulnerabilities. The site was predominantely a
> Sun customer so unfortunately a very large number of machines suffered
> from bug #4178455.
>
> Basically, nmap triggered a problem such that the next time you closed
> a scanned socket the machine would panic. It didn't panic right away.
> I'd run the scan weekly and a hapless sysadm would run:
>
> kill -HUP <pid-of-inetd>
>
> or try to shutdown the machine any time after that and his/her machine
> would panic.
>
> I was quite highly regarded amoung the admins around the site so they
> often turned to me for help. It was some weeks before I figured out
> the cause of the strange panics they were seeing (to be fair I saw a
> fair number myself as I owned more machines than most) and was able to
> suggest a patch. They were very grateful (less so when I admitted the
> cause).
>
> I dread to think how much time was wasted due to my careless scanning.
> The number keystrokes to weeks of confusion ratio was pretty high.
>
>
> The second is more likely to be repeated and thus perhaps more
> educational (with respect to learning from my mistakes and it is
> Linux-related). I don't recall exactly what I was doing but it was
> something like moving a bunch of files from /tmp/blah to an existing
> directory /opt/blah. I intended to do:
>
> root@host:/opt/blah# mv /tmp/blah/* .
>
> quite simple except I somehow managed to add a single space in (probably?)
> the worse place possible:
>
> root@host:/opt/blah# mv /tmp/blah /* .
>
> Thus moving /tmp/blah and everything (except /opt of course[0]) to
> /opt/blah.
> Obviously, nothing worked so I soon spotted what I'd done. Fortunately
> I didn't exit the shell.
>
> I tried to fix it:
>
> root@host:/opt/blah# mv * /
> bash: /bin/mv: No such file or directory
>
> But 'bin/mv' definitely was there[1]:
>
> root@host:/opt/blah# echo bin/m*v
> bin/mv
>
> So, obviously dynamic libraries were a bit broken. Then I remembered a
> trick
> using the dynamic loader directly to execute binaries:
>
> root@host:/opt/blah# lib/ld*.so bin/mv * /
> bin/mv: error while loading shared libraries: libselinux.so.1: cannot open
> shared object file: No such file or directory
>
> which felt like progress, so I tried:
>
> root@host:/opt/blah# LD_LIBRARY_PATH=lib lib/ld*.so bin/mv * /
>
> Bingo. Everything back where it should be . . . well almost everything
> cleaning up /blah had to wait until I'd had a large coffee.
>
> Regards,
> Mark.
>
> [0] mv: cannot move `/opt' to a subdirectory of itself, `./opt'
>
> [1] The shell still works so 'echo *' can be used instead of 'ls'. I knew
> this as I'd made mistakes and fixed other peoples many times ;-)
> I expect a brilliant sysadmin named Icarus Sparry taught me this the
> first time.
>
> [2] This is changing a bit with multiarch support. You might have to use
> the
> echo trick to find the right lib/ld*.so file
>
>
>
> --
> Please post to: Hampshire@mailman.lug.org.uk
> Web Interface: https://mailman.lug.org.uk/mailman/listinfo/hampshire
> LUG URL: http://www.hantslug.org.uk
> --------------------------------------------------------------
>
--
Rgds
RC
Robin Catling
Full Circle Podcast
--
Please post to: Hampshire@mailman.lug.org.uk
Web Interface: https://mailman.lug.org.uk/mailman/listinfo/hampshire
LUG URL: http://www.hantslug.org.uk
--------------------------------------------------------------
