Linked by Amjith Ramanujam on Wed 23rd Jul 2008 16:34 UTC, submitted by LinucksGirl
Linux In this article, learn how to be a more productive Linux systems administrator. These 10 essential tricks will lead you on your way to being one powerful Linux systems administrator. Learn about SSH tunnels, VNC, password recovery, console spying, and more. Examples accompany each trick, so you can duplicate them on your own systems.
Order by: Score:
Trick #11
by rexstuff on Wed 23rd Jul 2008 16:58 UTC
rexstuff
Member since:
2007-04-06

For lazy admins, they forgot an important one...

Trick #11: Don't run Gentoo

(oh, snap!)

I love Gentoo, run it on my home box, it has a lot of redeeming qualities but seriously - it's not for the unambitious.

Reply Score: 4

RE: Trick #11
by DRIQ on Wed 23rd Jul 2008 20:28 UTC in reply to "Trick #11"
DRIQ Member since:
2008-04-28

I don't want to be lazy, am downloading Gentoo right now. Have you got Flash to work on the 64 bit OS?

I believe my 64 bit Ubuntu is making me lazy. She is a very good desktop.

Reply Score: 1

RE[2]: Trick #11
by nbensa on Thu 24th Jul 2008 00:26 UTC in reply to "RE: Trick #11"
nbensa Member since:
2005-08-29

Yup. It works. I've moved my main two boxes from Gentoo 32 (installed back in 2002, Gentoo 1.2) to 64 a week ago.w

Reply Score: 1

fuser and screen collab
by parentaladvisory on Wed 23rd Jul 2008 17:16 UTC
parentaladvisory
Member since:
2006-12-18

Liked the tips about 'fuser -k' and screen collaboration, got to say, IBM has much fun to read about Linux in their DeveloperWorks section...

Reply Score: 2

RE: fuser and screen collab
by nick8325 on Wed 23rd Jul 2008 18:01 UTC in reply to "fuser and screen collab"
nick8325 Member since:
2005-10-06

I read your comment, wondered what fuser -k was, and ran fuser -k / to find out. Got quite a surprise! ;)

Reply Score: 1

RE: fuser and screen collab
by Doc Pain on Wed 23rd Jul 2008 21:48 UTC in reply to "fuser and screen collab"
Doc Pain Member since:
2006-10-08

Liked the tips about 'fuser -k' [...]


Regarding the trick "Unmounting the unresponsive DVD drive" I would suggest the -f flag to umount, and maybe the use of tools like camcontrol or atacontrol. I know the article is about Linux, but maybe there are similar tools.

# umount -f /media/dvd

would force the unmount of the media. If this is not sufficient, tools like camcontrol or atacontrol could be used to reset or reinitialize the ATAPI components (the drive or the whole bus) in order to clear any persisting drive locks.

Just an idea... :-)

Reply Score: 1

RE[2]: fuser and screen collab
by Kokopelli on Thu 24th Jul 2008 00:11 UTC in reply to "RE: fuser and screen collab"
Kokopelli Member since:
2005-07-06

I usually prefer doing a "lsof |grep [mount point]" to give me an idea of who or what is using it. fuser does not do as good a job in my experience, which is admittedly me trying fuser after reading the article.

Taking as an example playing a movie file from a mounted USB hard drive. fuser /dev/sdd1 or /dev/sdd or /media/disk will generate no output. It will only generate list the culprit if you do do "fuser [file that is open]".

You can force unmount but I find 99% of the time you can cleanly do so once you figure out what is preventing the umount.

NOTE: "lsof +D [mount point]" does the same thing, piping to grep is habit

Edited 2008-07-24 00:30 UTC

Reply Score: 2

RE[3]: fuser and screen collab
by jhoo on Thu 24th Jul 2008 15:12 UTC in reply to "RE[2]: fuser and screen collab"
jhoo Member since:
2006-03-24

NOTE: "lsof +D [mount point]" does the same thing, piping to grep is habit


Just to be a pedant, it doesn't do the same thing, it does something markedly different, however it does often produce the same result.

Actually the results can be very different, take for example the case of "lsof +D /bin/" which will find any open files under /bin and "lsof |grep /bin/" which will find any files with /bin/ in their path e.g. files in /usr/bin as well as files in in /bin.

Reply Score: 1

RE[2]: fuser and screen collab
by Bending Unit on Thu 24th Jul 2008 10:48 UTC in reply to "RE: fuser and screen collab"
Bending Unit Member since:
2005-07-06

A desktop operating system should not lock the drive in the first place. I have never liked that thing about unix-like systems. Removable devices have always been error prone on my Linux systems.

Reply Score: 2

RE[3]: fuser and screen collab
by B. Janssen on Thu 24th Jul 2008 12:43 UTC in reply to "RE[2]: fuser and screen collab"
B. Janssen Member since:
2006-10-11

A desktop operating system should not lock the drive in the first place. I have never liked that thing about unix-like systems. Removable devices have always been error prone on my Linux systems.


Phew, lucky us that TFA explicitly mentions enterprise level GNU/Linux servers.

Regardless of desktop or server, it is just bad policy to eject a removable media while somebody/thing is accessing it. Really. Remember the pain older MS Windows releases would put you through by reliably crashing if you'd tried something like that?

Reply Score: 3

Trick #5
by BSDfan on Wed 23rd Jul 2008 17:24 UTC
BSDfan
Member since:
2007-03-14

It's not a "Linux trick", it's a documented OpenSSH feature that works on any supported system.

He could have saved a step as well...

His first command on 'ginger' was:
ssh -R 2222:localhost:22 thedude@blackbox.example.com

..and then this on 'blackbox':
while [ 1 ]; do date; sleep 300; done

A better alternative would be:
ssh -Nn -T -R 2222:localhost:22 thedude@blackbox.example.com

Read the man page to learn what they do.. ;)

Reply Score: 4

RE: Trick #5
by shapeshifter on Wed 23rd Jul 2008 19:01 UTC in reply to "Trick #5"
shapeshifter Member since:
2006-09-19

It's not a "Linux trick", it's a documented OpenSSH feature that works on any supported system.

He could have saved a step as well...

His first command on 'ginger' was:
ssh -R 2222:localhost:22 thedude@blackbox.example.com

..and then this on 'blackbox':
while [ 1 ]; do date; sleep 300; done

A better alternative would be:
ssh -Nn -T -R 2222:localhost:22 thedude@blackbox.example.com

Read the man page to learn what they do.. ;)


No, it's a Ubuntu trick.
I know because I saw it a while back on Ubuntu forum.
Pretty sure it was before I saw it anywhere else.

Reply Score: 3

RE[2]: Trick #5
by nbensa on Thu 24th Jul 2008 00:28 UTC in reply to "RE: Trick #5"
nbensa Member since:
2005-08-29


No, it's a Ubuntu trick.
I know because I saw it a while back on Ubuntu forum.
Pretty sure it was before I saw it anywhere else.


Oh! C'mon!!!! Ubuntu hasn't invented anything! And the latest version sucks big time.

Reply Score: 1

RE[3]: Trick #5
by Kokopelli on Thu 24th Jul 2008 00:32 UTC in reply to "RE[2]: Trick #5"
Kokopelli Member since:
2005-07-06

shh.... Hear that? No? That is the comment whizzing over your head.

Reply Score: 3

RE: Trick #5
by jhoo on Thu 24th Jul 2008 14:51 UTC in reply to "Trick #5"
jhoo Member since:
2006-03-24

It's not a "Linux trick", it's a documented OpenSSH feature that works on any supported system.

No one ever said it it was a "Linux trick", these are "tricks for Linux admins" the fact that it is applicable to other OSes doesn't make it any less applicable to Linux, likewise the fact that it is documented doesn't make it any less of a "trick". Many items on the list aren't specific to Linux and all of them are documented somewhere.

Read the man page to learn what they do.. ;)


I think that was the second point in his conclusion.

Reply Score: 2

reset
by righard on Wed 23rd Jul 2008 18:42 UTC
righard
Member since:
2007-12-26

I like the reset command, when my terminal scrambled I always used 'cat /dev/urandam' until it was was fixed again.

Reply Score: 2

Wow...
by Dirck on Wed 23rd Jul 2008 20:12 UTC
Dirck
Member since:
2008-07-23

You are a "Linux Certified IT professional working for the IBM Linux Clusters team" ???????

"10 essential tricks"..duh?..

...Dammm you get overpayed..

Reply Score: 0

Good article
by acamfield on Wed 23rd Jul 2008 20:53 UTC
acamfield
Member since:
2006-11-17

We learn well what we use often. I use ssh, scp and screen every day. It's always good to read how others use these utilities to be reminded of functions we may have forgotten. Nice style of writing, too. It's good to see that Linux is doing good things for IBM. It hasn't been too long since reading anything technical from IBM was bound to put you in a comma.

Reply Score: 2

Trick 4: Getting back the root password
by frank on Wed 23rd Jul 2008 22:12 UTC
frank
Member since:
2005-07-08

Regarding Trick 4: Getting back the root password

Is it possible to do something similar with lilo?

Reply Score: 1

dcwrwrfhndz Member since:
2006-05-26

I think that last time I used lilo it was about 6-7 years ago, but if I'm not wrong typing linux single at the lilo prompt should work.

Edited 2008-07-23 22:42 UTC

Reply Score: 5

Does this guy actually know anything?
by tadams on Wed 23rd Jul 2008 23:41 UTC
tadams
Member since:
2008-07-23

"You'll see output in both screens telling you what the speed is. On a normal server with a Gigabit Ethernet adapter, you will probably see about 112MBps. This is normal as bandwidth is lost in the TCP stack and physical cables. By connecting two servers back-to-back, each with two bonded Ethernet cards, I got about 220MBps."

1 Gigbit per second is either 1073741824 bits per second or 1000000000 bits per second. Depending on the definition (binary or standard). To get bytes divide by 8 (bits per byte). 134,217,728 or ~134 megabytes per second. This doesn't include the overhead of the TCP/IP stack. (Many people divide a rate by 10 to get an approximate value AFTER overhead; which would give you 107 megabytes per second.) You will see his number, which is somehow magically low due to losses in cables is right on the money.

My point, you don't lose bandwidth in the cables unless they are causing errors. Bandwidth is also NOT lost in TCP/IP, or other, stacks. It is simply consumed for necessary overhead.

This guy wouldn't work for me making such stupid comments.

Reply Score: 0