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.
Post a Comment
Member since:
2007-04-06
Fans: 0
Member since:2008-04-28
Fans: 0
Member since:2005-08-29
Fans: 0
Member since:
2006-12-18
Fans: 0
Member since:2005-10-06
Fans: 0
Member since:2006-10-08
Fans: 6
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... :-)
Member since:2005-07-06
Fans: 2
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
Member since:2006-03-24
Fans: 0
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.
Member since:2005-07-06
Fans: 1
Member since:2006-10-11
Fans: 2
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?
Member since:
2007-03-14
Fans: 2
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.. 
Member since:2006-09-19
Fans: 0
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.
Member since:2005-08-29
Fans: 0
Member since:2005-07-06
Fans: 2
Member since:2006-03-24
Fans: 0
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.
I think that was the second point in his conclusion.
Member since:
2007-12-26
Fans: 0
Member since:
2008-07-23
Fans: 0
Member since:
2006-11-17
Fans: 1
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.
Member since:
2005-07-08
Fans: 0
Member since:2006-05-26
Fans: 1
Member since:
2008-07-23
Fans: 0
"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.
