Yesterday someone gave me a link… The 7 deadly Linux commands

It sounded interesting, so I started to read. The whole thing was about 7 ways to (permanently or temproraily) kill a Linux system. I picked 4 below.

I didn’t trust my eyes, not only that the initial article has some really serious bugs, especially the comments are really amazing. That looks like an own “dailyWTF” for administration!

The initial article

• #1: rm -rf /: This definitely can work but the author simply forgets to mention that you may need to gain some interesting permissions first, you know: God, root - where’s the difference?
• #2: The hexified literals: Every kid can decipher that, provided it can read wikipedia articles or somesuch - heh
• #4: The good old Bournish fork bomb: How nice - but with proper ulimits set, nothing interesting will happen (though some comment explains this as “has been fixed in modern systems” - as if it was a bug or so…)
• #7: mv /home/user/* /dev/null: That’s a nice one, especially when you believe the article, which says that your files will be lost, away, gone - because /dev/null is the bit bucket! Amazing! Even if I’m root, the only thing I’ll loose is a device node Beside the fact of target file not being a directory and whatever else you can hit here.

Provided that the author really meant it serious, and the article was meant to warn newbies, that’s not that bad afterall. Newbies don’t need details in their first days - and this article is meant to make their system survive until they know the details. The intention isn’t bad, so.

The best: The comments!

I would have expected that 99% of the comments to this article are from people who shake head and maybe explain the wrong stuff a bit - but no, just a few comments are okay, looks like handselected. Many comment were just more technical crap!

I picked one “comment thread” to show you, many others were not really better:

rm -fr * is the same as rm -fr /

• The very first comment says that! rm -fr * is the very same. Let’s follow the thread.
• Some guys (”Chuck” and others) corrected this comment, with a brief description what the difference is.
• “jdhore1″ explains why rm -rf * must be the same: “* means everything that includes the . and the .. you see when you do ls -a” and “On unix machines this will jump a directory [...]“. That’s not enough, here a small hammer: “[...] this doesn’t apply on most kernels [...]“ - just make your own thoughts about this stupidity! This guy will be the first one who crashes his system because of dangerous half-knowledge, not a newbie.
• Finally a guy who knows what he’s talking: “I know of no shell in all history that has included . and .. in * globs by default.” - maybe the world isn’t as bad as I though until this comment!

Have fun reading the entire page. It’s worth, you’ll feel better afterwards.

Ha - I found a really nice one, one trying to be smart and correcting the article’s point #7 (mv to /dev/null) a bit:

“You can change the last one (mv /home/yourhomedirectory/* /dev/null) to this: mv ~/* /dev/null”

….which is of course correct, but what bugged me on that comment is the name and the blog-link of the commenter: The Unix Geek

Hell, why doesn’t a guy named “UNIX geek” provide corrections? Instead he behaves as if everything told above was correct and right… Get another name, dude.

And people, think about one thing:

Your job as system administrator is safe, regarding all the alternatives that published their “skills” on that page!

]]> http://www.thebonsai.net/2008/11/21/why-some-people-better-shouldnt-play-admin/feed/ http://www.thebonsai.net/2008/11/19/der-pimped-shellcompilerinterpretiererdings-gti-16v/ http://www.thebonsai.net/2008/11/19/der-pimped-shellcompilerinterpretiererdings-gti-16v/#comments Wed, 19 Nov 2008 21:59:09 +0000 TheBonsai http://www.thebonsai.net/?p=69 Schock! Was lernen die Leute eigentlich im Programmierunterricht?

Nichts spektakuläres eigentlich - sowas machen die “coolen Profis” die sich “schon Jahrelang mit Computern beschäftigen” und eigentlich “alles kennen und schonmal benutzt haben” beim Einstieg in Linux immer

Okay, der Fragesteller mag nicht so einer sein, aber viele sind so! Und dann kommt meistens nur Datenabfall dabei raus…

Der Code im ersten Posting muss von mindestens 2 Interpretern/Compilern bearbeitet und vorher mit der Pinzette auseinandergenommen werden…

http://www.linux-forum.de/berechnung-von-pi-20931.html (erstes Posting)

Unfortunately, the IDs of these entities depend on the point in the installation process where you install the SUSE orarun packet, since the UID is generated on the fly. This leads to trouble here and then (nothing serious, but it’s a bit of work to fix such an issue afterwards). Of course I think the installation procedure of the SLES orarun package should use a fixed ID here, but that’s something SUSE decides, not me (it tastes like a bug).

NFSv4 and its ID mapping - sounded interesting, and sounded worth to have a look. For this particular case, I was really only interested in the ID mapping, regardless other great features NFSv4 comes with. I made a test setup to check if it could help me out of these and similar issues.

The test setup was a simple server/client pair with OpenSUSE 11.0, to have a recent NFSv4 implementation. Named testusers on both systems existed, with different IDs of course. I first was excited, since everything worked as expected. The ID mapping did its job and I was able to work on both ends of the NFS connection, like there were no differences.

But one thing that bugs me: If you set file ownership numerical, or create a file using creat() or open(), the ID mapping doesn’t work. The situation is clear, of course. Numerical IDs are set directly, so the NFS server gets the numerical ID of the user on the client, can’t map it locally, and reports it as “NFS unknown user” over the link. That means, you (as generally mapped user) touch a file, and afterwards it belongs to “nobody”. A chown afterwards “fixes” that, of course.

What I would have expected from a usable implementation: That the machine which is commanded to set a numerical ID (for example by a simple creat() call) first tries to reverse-lookup the ID to a name and uses this name on the NFS link. If the reverse lookup fails, there’s no other way to behave like it does now, of course. But that additional lookup would help a lot. What do I need ID mapping for, if I can’t use it in 100% of the cases? If I need to use identical IDs or a central user database, I can stay at NFSv3 because the additional features NFSv4 brings don’t weight that much in our common installations. It really would have been nice if the implementation did that, unfortunately it didn’t (and - assumed the technical possibility is there - since the answer on the mailinglist was relatively clear, I don’t think it will be implemented).

Sooner or later, of course, NFSv4 will replace NFSv3. In which limited or full featured implementation ever. NFSv4 is the better protocol.

UPDATE:

I want to make clear that I know the ID mapping is not meant as “end-user feature”. It’s needed to adapt the system to the name-only driven protocol. I just hoped I would have advantages using the mapping

Damien Sandras has released the Version 3.0 of his Ekiga software phone.

This is a major release, most of the code has been rewritten. Many changes are not visible because they are in internal code. See the feature list (major new features are in bold-italic font):

Developer Features Version 3.0.0

• Ekiga Engine, independant of the GUI, reusable in other projects

Ekiga.Net SIP VoIP Service

Due to the new presence support of Ekiga, the free SIP service Ekiga.Net will also be tuned a bit. It gets a new router software and a new webinterface.

Since there are many things to take care of, especially the user databases and similar vital things, this won’t happen today or tomorrow.

Why do I advertise Ekiga?

I don’t advertise. It’s a FOSS project I’m involved in my sparetime, so basically I just wrote what others and I did in the last weeks and months.

Due to a new toy we got at work, I was searching how to massively speed up BZIP2 processing on GNU/Linux systems. It sucks when you have 16 cores but only one process/thread.

I finally found PBZIP2, which basically is just a new controll wrapper around the underlying library (the code has around 60 Kilobytes - with comments and all). It builds in about the half of a second.

Just to imagine a bit:

Test file was a 5.6 Gigabyte file with random binary data (/dev/urandom). A normal BZIP2 took 30 Minutes to finish, a parallelized PBZIP2 made the same in 3 Minutes and 30 seconds.

In case you need to speedup BZIP2 processing on your SMP-servers, consider to use PBZIP2 - it rocks!

someone in chat just called me a CCC.

A CCC is a simple machine that takes input in the form of coffee and produces output in the form of (C) code. Means, a CCC is a Coffee to Code Converter (also: Coffee to C Converter).

What a world - what was your today’s nickname?

Finally I’m back coding for the Ekiga project.

Though I have some trouble interpreting the new code structures and paradigms, it gets better every day. I focus on GTK+ UI coding (in C), which is tricky enough sometimes.

Have a nice week!

Ich bin mal wieder über eine nette Seite gestolpert, die darstellt was der Wirtschaftszweig IT von Wettberwerb und Fairness hält: TCPA

Ich lasse mich jetzt zu keiner politischen Aussage hinreissen, es soll sich jeder selber denken wie die Zukunft der Menscheit aussehen kann. Das hat nämlich nicht nur mit wirtschaftlicher Kundenbindung zu tun.

Auch so ist die Seite ganz nett und informativ - es lohnt sich auf jeden Fall mal durchzuklicken, selbst wenn vieles übertrieben dargestellt ist.

In diesem Sinne einen schönen Arbeitstag (wenn der TCPA denn damit einverstanden ist)!

Yesterday I did a dist-upgrade for my workstation. Nearly everything worked as expected. Some manual interaction here and there, but okay. Finally I rebooted into the new system, got my IP by DHCP and… nothing. I was’t able to logon.

You have to know that I use centralized LDAP-based authentication, which isn’t always bullet-proof. So I searched in this direction first. Started into singleuser mode - oh wonder, everything worked as expected, I was able to change users and stuff. I played a bit with these LDAP configs to be sure - they really worked, they were sane! So… why the hell… I reconfigured init(8) to give me a blank shell on a specific virtual terminal and rebooted again into runlevel 2. As expected, I wasn’t able to logon - but on VT6, I had my tinker shell

It was clarified very fast. I checked my current IP and… there was none. I could swear I got an IP on every bootup! What happened? Well, the dist-upgrade also installed the shiny and nice piece of crapsoftware called NetworkManager. After getting an IP by DHCP, the NetworkManager was started and had internal communication problems (on the DBUS?). Because of these problems, it immediately took the IP interface offline - throwing away my IP and making network communication - including LDAP for authentication - impossible.

I have no clue why NetworkManager was installed during the upgrade, it wasn’t active before!

The rest of the upgrade scenario was quite normal and common. Around 2,5GB of installed data was moved and reinstalled, and the system booted like nothing happened - all hail APT!

Nun, endlich die Ausbildung hinter mir, ich darf mich jetzt offiziell

“Fachinformatiker, Fachrichtung Systemintegration“

schimpfen. Kling komisch… is aber so

J.