This topic was created by diodesign .
Arch Linux is an intimidating distro for the newcomer, but everyone should try it. The reason I mention it here is the documentation is phenominal for linux users in general: wiki.archlinux.org
Centos is a good distro to learn for server use, and most usefully Redhat's documentation is online - it is a the same lineage - with Kickstart being a good place to learn scripted deployment (versus imaging).
On the BSD side I've found FreeBSD beautifully simple to administer; package (port) management takes a little more learning though.
as a compliment to web sites - meet other guys with beards and spectacles. You pick up more than just the problem that you have today and get to make friends. Try this one in Newcastle at the end of March:
Rule #2 : Read the man pages.
This is SO key, but many newbies miss this. You should have man pages installed by default and this is your best resource.
man <command>
e.g. man lvm
man -k lvm does a keyword search and gives you a list of pages relating to LVM.
once inside the man page, use slash (/) to search for FILES or SEE ALSO (literally type /SEE ALSO) and it will hop you down to some useful bits.
If a man page is in a certain section, then you need to specify that.
man 1p zcat gives you the zcat command from section 1p.
HTH.
Definitely, the manpages are excellent, except for coreutils for which the complete documentation is here:
http://www.gnu.org/software/coreutils/manual/html_node/index.html
If you're writing C code, then the manpages of the Linux Programmer's Manual (the "manpages-dev" package in Ubuntu) are extremely useful, and often better as a first reference than the glibc manual. They're useful even when you're writing Python or Perl, since so many functions in higher-level languages are just wrappers for the C functions.
I use man2html to allow me to read man pages in a browser. It gives you some creature comforts like scroll bars, a variable-width font, and links you can click on. And if my local man repository doesn't have the command I need, I use http://manpages.ubuntu.com/ . You don't have to be hard core to be a good Linux admin.
I have to put a big caveat in here, that SOME man pages are excellent. But there are so many full of endless cruft, and it's a fairly unintuitive format - obviously written by old-school engineers.
When I was a real newb, I was endlessly frustrated with the endless advice to "read the man page" when I needed a quick one-line solution to an issue. WHICH man page? (Sorry, man -k can find even more cruft.) Then multipage listings of obscure switches that are never used in real life and lengthy explanations of underlying architecture can make it almost impossible to get to the info you need. Not to mention the idiosyncratic format and use of conventions that a naive user find difficult to decipher.
The famous example of sudoers 5 is a great case in point. Ok, after traversing many many pages, you get to some examples of how the thing might work, but wow, it's a mission.
So, sure, I think any documentation is better than none (a particular curse for opensource), but the accessibility of many of those pages could be vastly improved.
* When ordering a Dell PowerEdge server, don't forget to buy the Enterprise DRAC and get it wired up. Provides a Web interface for the status of the machine, virtual media (yes, another way to install the OS without needing PXE boot) and, most importantly, a VNC terminal session to the main hardware (right from power up, BIOS, grub and the OS!).
* Install OMSA on PowerEdges, just for their "reboot recovery" option (if the kernel hangs, you can set it to wait so many seconds and then cold reboot the server).
* I like using rdist to keep customised system files synchronised across Linux servers and desktops. Think of it as a "networked make" utility and it's extremely handy once your server count gets into double figures.
* I use rsync to sync the system disk partition to another identical partition once a week via cron. In fact, it's a bit trickier than that (you have to change grub.conf and the copied /etc/fstab) so I've got a script to do it, but basically if I mess up the original system partition, I can boot into the second partition as an immediate rescue. Most useful if you run the sync script just before doing "yum update" (it allows you to roll back the update by rebooting into the pre-update partition).
* nagios for monitoring of course - install nrpe on the clients (yep, we rdist our custom config for nrpe) and then add the clients to the nagios server setup (we wrote a script for this part). With Dells that have OMSA installed, there's nagios modules to check OMSA info (e.g. temperature) and even some disk controller statuses.
* LDAP for authentication - quite tricky to setup, but useful when it's working properly. Don't forget to leave root as a local user in case the LDAP server goes titsup!
* amanda 3.X for tape (or even disk) backups. Amanda 2.X was dumb about autoloaders so we had to write a lot of custom wrapper scripts to check tape barcodes, load from autoloader, put back etc, but 3.X is actually good with autoloaders at long last. Now has (mostly) working Windows Amanda clients so we've even started backing up Windows clients too. Server-side encryption and compression are bonuses too (replace gzip with pigz in the Amanda server config if your tape server has many CPU cores).
* For VMs, we mostly use Proxmox VE in a clustered setup with KVM-based VMs (a mix of Windows and Linux clients). It's probably not as slick as VMware, but it's a *lot* cheaper! To be honest, I tried VMware a few years ago and couldn't believe it prompted you to rebuild kernel modules interactively as part of the boot sequence if you updated your kernel RPM and rebooted your VMware server. What if you didn't have console access at the time?! They've probably fixed this awfulness by now, but I couldn't believe how naff that was at the time.
"* When ordering a Dell PowerEdge server, don't forget to buy the Enterprise DRAC and get it wired up. Provides a Web interface for the status of the machine, virtual media (yes, another way to install the OS without needing PXE boot) and, most importantly, a VNC terminal session to the main hardware (right from power up, BIOS, grub and the OS!)."
Actually, since we are talking Linux here, the iDRAC express (the standard one) will allow you to set it up so that it gives you BIOS, Grub and the OS via the serial console. A pig to set up, but once done allows you full access to the hardware without having to pay the extra for the Enterprise licence....
Won't work for Windows though...
www.cmake.org believe it or not... this make file generator is great for automating the configuration of linux. It has the ability to script, generate files from templates, a full suite of file manipulation commands, and to top it off integration with the tools ctest and cdash. Setup tests that confirm your desired configuration and then have those tests posted on a web based dashboard.
cmake- it ain't just for making make files .
[I acknowledge that there are better configuration management systems out there. BUT for those forced to homebrew their own for whatever reasons (such as no external internet connection because of security) this tool rocks. Not to mention you can find thousands of people who already know cmake.]
Your best bet, at least to begin with, is to choose a linux family, for instance debian-based distributions include debian, ubuntu and a variety of other offshoots, RHEL includes Redhat, centos, oracle linux etc. Stick with one family of linuxes for the first few months and you'll learn enough to be able to work around the nuances of the others, rather than lamenting your apparent lack of google-fu prowess when a configuration file in one family has moved to some obscure location in another.
The arch wiki (and to a lesser degree the gentoo wiki) are some of the best tools to look for info - regardless of what distro your using IMO
https://wiki.archlinux.org/
If your a sysadmin who has to deal with 100+ Redhat based servers I suggest spacewalk - it is by far the best tool of its type.
Here's a nice one liner - shows top 10 highest connections through iptables (using for a bridging firewall..)
tcpdump -tnn -c 20000 -i br0 | awk -F "." '{print $1"."$2"."$3"."$4}' | sort | uniq -c | sort -nr | awk ' $1 > 100 '
If you are going to do it more than three times, script it.
OK, maybe cron.
If you are getting good at bash scripting, and want to use cron to run them at scheduled times for some reason they run fine when you run them manually, but fail when run by cron change the first line in the script to:
#!/bin/bash -l
The -l argument specifies a login shell. If your usual login sets a lot of environment variables this can quickly sold a multitude of strange problems.
(Very useful for scripting oracle schema exports/imports.
McGeneration does not really know what fancy words such as "philosophy" mean. They are attracted by shiny presentations, though. They can "see the quality of anything with a single glance".
They want Immediate Gratification and that is why anything Unixoid is above them.
Many good ideas are already posted, but I didn't see logs. When a problem arises, it is probably logged somewhere. If you are still learning your way around, the log files will give you great ideas about what to study next. If you havn't got an issue at the moment, you may see something interesting to follow up on.
I just had a problem with a networked scientific instrument connected to a Windows machine (what can you do? the instrument makers write the software). The problem had to do with bootp, and the logging option was off. I turned logging on, restarted bootp, and got the clues I needed to fix the problem with a simple change to the hosts file. Without the log information, it probably would have been a while before I thought about checking that.
All you really need is ksh93. (It has builtins for almost everything or can).
(And to understand the design of why UNIX was implemented like it was).
It is becoming harder to do though (Mainly due to the actions of one Redhat creator of systemd/pulseaudio/avahi).
If I was starting now I would probably try to learn on Solaris 9 in a VM. (Or a BSD) what you learn is fairly transferable. Both of them have manpages that are fairly decent and not blatantly wrong.
The way Linux is going is similar to XP there is hundreds of ways to do stuff and was a new way each week almost. They have started using loads of binary only stuff instead of text also which complicates things.
At an early stage of my Linux apprenticeship I had the chance to discover their web site ( http://www.linuxfromscratch.org/ ) and I had the patience to give it a try. It takes some time to do it but at the end, besides the satisfaction of having built your own Linux distribution you will come enriched with invaluable knowledge on how an OS is working internally. This experience is distro neutral so after that you will feel at ease in front of any flavor of them. Also another important gain is that you will never feel intimidated by the sequence ./configure, make and make install, ever. Add to this reading on CentOS website about when is appropriate to compile from source and when it is not ( http://wiki.centos.org/PackageManagement/SourceInstalls ) and you've just made a long way towards safeguarding you mental sanity as a *nix sysadmin.
In the end, for those who feel ready to begin their journey in the land of Tux I will recommend as a starting point the IBM Developers website ( http://www.ibm.com/developerworks/linux/ ). They have a good collection of tutorials there.
I'd vote for nano as a really useful tool. It's a bit less obscure for a quick tweak to a config file than vi or emacs.
The awk and bash HOWTOs have been very helpful in teaching me script programming, I even managed to type a one-liner without looking anything up and had it work first time the other day.
In fact, the tldp.org website is a great help in understanding all sorts of Linux things.
Start with the POSIX command set since they are available everywhere (including Windows with SFU). All the other commands should be considered gravy and learned as secondary but nicer ways to work which may or may not be available on a random system you end up working on. Remember that the Linux admin will also be the guy they call for random Unix jobs :)
I like to use 'watch' quite a lot to give me a live output of commands like 'du -sh'
It's not very pure and it's been a while since i used it but when i was first faced with a linux server i found webmin to be a life saver until i learned how to do simple thing like add a user or restart a service.
I like 'iptraf' too for a quick look at whats going on with a nic.
'startx is also quite an amusingly obscure way to start the desktop, always makes me smile when a new person see's me do that when they have spent the past 45 minutes fumbling around trying to do something.
My advice to new comers is always to use linux as your main os for a while, no dual booting or having a VM on your windows laptop. The problem with that is that as soon as you hit a problem that will be faster to get around by going back to windows, you'll go back to windows and learn nothing.
Dive in, be prepared to do some reading to be able to get yourself up to the same level that you are with windows. Once your there then you will find that you can do an awful lot more with linux.
I found Debian to be a wonderful and easy to use linux, i recommend it to anyone and personally i find it much easier to use that the redhat's out there.
One definately worth looking at is nagios. Know where and when there is a problem.
Need to know more about a command or related commands? Use "man" and "apropos".
Definately learn shell scripting (usually thats bash nowadays). Thats for repeating tasks and cron jobs.
Netcat and openssl are invaluable tools for debugging servers (unencrypted/encrypted respectivly).
Log files, log files, log files. Yes, they are an invaluable tool for finding errors.
While we are at that, grep. Grep is your friend.
Lots more, but those are just the first important things that came to my mind.
If you really want to master Linus system administration:
0. Take a LSB course
1. Linux from scratch
2. Choose family
3. Master the package manager (pkg/apt or rpm/yum,zypper,..)
4. Learn basic vi
5. Learn basic regex
6. Learn to script, start with basic bash later you can matter python
7. Learn autoyast (side family)/kickstart (red hat family)/preseed (Debian family) for fully automated OK installation
8. Learn puppet/chef
By then you've got a few years of experience.
If you're going to learn puppet or chef then you should invest your time to learn ruby instead of python. It's mandatory anyway for chef, and puppet is written with it. Puppet templates can contain embedded ruby, and its also useful when writing your own (facter) facts. It's incredibly easy and quick to use for general purpose scripting tasks too.
Network the boxen together (freely available Celeron boxes with built in 10baseT will work nicely for this exercise, or 10base2 "thin net" if you don't have a spare hub). Use the Slackware boxen as "users", and the BSD box as "server". Create several user logins on each box. Along with whatever GUI you use on the main screen, hang a dumb terminal off a serial port on each box, and send it a login prompt. Handy when the GUI goes tits-up.
Then find a copy of the Coherent Lexicon, from Mark Williams Company (try used book stores in University towns). Read it, cover to cover. Yes, including the rather excellent Taylor UUCP tutorial[1]. Try the examples on the Slackware box as a user. Become root, if needed. When you break a Slackware box, learn to repair it in situ, without re-installing the OS.
When you're done with that, get a copy of UNIX Power Tools (O'Reilly). Do the same as the above.
If/when you get stuck, read the man pages; "apropos" and "whatis" can help. Do not ask questions on user forums (Usenet, etc) until you have done a thorough search online ... somebody, somewhere, has already asked & had the exact same problem answered.
Concurrent with this, enroll in "un*x sysadmin 101" (or equivalent) at a local JC/Poly.
Sound old-school? Absofuckinglutely. But you can't run before you can crawl.
[0] If you don't already know vi & sh inside out, start with those. See "run" and "crawl", above.
[1] I still use UUCP on internal links for a Usenet system I consult for. I also use it to move email between departments at a couple of Fortune 150s. I'll leave the "why?" as an exercise for the reader.
Thing is, AC, that it doesn't really matter if it freaks 'em out. It's the truth. Simply installing *buntu, or OS X Server, or a Windows Server, doesn't make you a sysadmin. Even though, technically, you are the admin of that particular box.
If a scholar wishes to become an actual, real-life Systems Administrator, s/he has to understand & use the CLI (and what run levels are, the difference between scripting, compiling and assembling ... etc., etc., etc.). This is true of every major server system that I'm aware of. Yes, including those from Cupertino & Redmond.
The bottom line is that if you can't handle the CLI as a day-to-day desktop, you're not cut-out to be an actual SysAdmin. Yet. But it's always possible to learn. There are no short-cuts, no "magic fix it pills". It takes time, hard work, sweat & tears ... and the occasional embarrassing gaffe, some of which are firing offenses. Just like any other profession worthy of calling one's own.
A very good piece of server monitoring software can be found in Xymon (Hobbit as was). Great for quick glance monitoring state of server farms. Knocks spots off the paid for IBM Tivoli Monitoring.
The other is Webmin which is a great admin tool - you can farm out some administrative tasks easily to people with no special privileges, reducing the danger of people finding ways to circumvent sudo. (Ours was used to allow help desk people to set up printers across platforms without needing to know the quirks of each of the different command lines)
Become very good friends with ssh and byobu or screen very early, even if running a local vm. Once it's installed and the network is running, switch to ssh. In the past 3 years the only time I've used a console connection on a linux/unix server was on a lights-out console to see a kernel oops in proxmox had caused everything to stop.
Don't be afraid to be creative and break things. Once you've broken it spend time trying to fix it before getting someone else to sort it out. You remember it faster for the next time it breaks.
<search engine of choice> is your friend, nobody expects you to remember everything.
Less is better than More
Tmux (or screen).
Get comfortable with vi, it's everywhere.
strace for those hard to track down problems.
lsof can tell you a lot about what a process is doing.
dstat is handy for getting an overview of system performance.
As others have pointed out - read the man pages. Don't just blindly copy and paste stuff from tutorials.
Just build and break a bunch of stuff (in VMs or wherever).
One of the hardest things for new comers to wrap their minds around is that they don't know how to ask the right questions. Someone even wrote a very famous and effective howto about it:
http://www.catb.org/~esr/faqs/smart-questions.html
John H Woods is right about dd and if you are talking to new sysadmin I would throw in ddrescue too:
http://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html
In my opinion best way for new users to get to know Linux is by using VirtualBox in windows until they have learned enough to be comfortable with partitioning their drives.
My thoughts on LFS for new users are mixed. Yes you learn a lot, but you don't know what a lot of it means. Once you are done with it you can go on to BLFS but most people I talk to are ready for a package manager at that point.
Source based distros are my favorite way on my PC so when my friends are ready to dive in I show them Arch and Funtoo.
This is the "Everything Within" book for Unix and Linux beginner admins. Although 20 years since the first edition, and more than ten years since the last, this book still cuts the mustard. Eminently readable, and crammed with beginner tips, but most importantly an introduction to the 'nix mindset. Just remember that for the details, time has not stood still, and check the man pages for the tools you actually have installed/are using.
Unix Power Tools, Third Edition
By: Jerry Peek; Shelley Powers; Tim O'Reilly; Mike Loukides
Publisher: O'Reilly Media, Inc.
Pub. Date: October 28, 2002
Print ISBN-13: 978-0-596-00330-2
Pages in Print Edition: 1160
Give them a copy of http://www.amazon.com/UNIX-Linux-System-Administration-Handbook/dp/0131480057 to get them acquainted with the OS and of http://www.amazon.com/Practice-System-Network-Administration-Second/dp/0321492668 to undestand what being a sysadmin is (this latest book is platform independent, I wish more Windows admins read it).
As a comment to your article http://www.theregister.co.uk/2013/02/21/linux_isnt_that_hard_really/ stop cloning linux vm's. Learn how to use kickstart for redhat distributions, mirror internally the OS repositories (mrepo https://github.com/dagwieers/mrepo is quite easy to setup) and spinning a new vm will take you 3 minutes with the latest updates. Yes, really.
Your rants on the ifcfg-xxxx files for configuring nics on redhat based distributions are quiet funny. You try shoehorning your windows admin practices on other types of systems and you run into problems. Stop doing that! Kickstarting the OS with a clean, unattended installation will solve all your problems about that particular point. It really is a non issue for most people except the ones cloning vms.
The network config files of redhat are very easy, are very well documented (https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/ch-Network_Interfaces.html). The documentation for redhat systems is simply excellent: https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/ , as a linux admin using redhat based distros get familiar with it. Stop using forums to find your answers and start reading the fine manuals, they are there for a reason.
Learn how to use the vi editor. Yes, you have to. No, this is not optional. Sooner or later you will need to do something on a system with that one as only editor available, so you might as well just get used to it. You do not need to be a vi guru, just be able to edit a file.
Learn how to write your own shell scripts. Read other people's scripts. Understand them.
Learn a high level scripting language. Lots of admins know Perl, Python is fine as well.
Learn how to troubleshoot your system. Where are the log files, how to bump up debugging for the various subsystems, how to turn services on and off, how to find info on those services and subsystems without an internet connection (yes, it happens that you are cut off the net and you have a problem).
If you have to work with readhat distros, learn to like selinux. It is your friend and might save your ass on those internet facing servers when they get owned by a faulty web app deployed by hit and run ruby on rails developers (or php, or python or ....)
Once your really understand how a linux computer works, then you can start scaling out with cfengine/puppet/chef/ansible, whatever.
All the above things will make your junior admins better Windows admins as well. They will understand how protocols work and they will concentrate on finding the solutions to their problems instead of just clicking around without really knowing what they are doing in their shiny tools.
If your junior admins are not willing to do this, they should be forced by management. If they still do refuse to do it, get new juniors admins. If the company wants to run linux servers, admins need to support it. It is that simple.
Back in the day when I was cloning E10K domains running Solaris 2.6/7/8 and JET wasn't around I had to use a combo of
1) ufsdump over NFS to the SSP
2) transfer the ufsdmp to the new SSP/E10K
3) jumpstart interactive the newly prep'd E10K
4) ufsrestore via NFS the ufsdump
5) THEN to get round all things network and /dev - do ...
5a) run/usr/sbin/sys-unconfig
5b) rm /etc/path_to_inst
6) boot the domain OK> boot -arv
and hey presto the domain booted 'as a fresh install' and rebuilt it's device tree
In modern times - when cloning ESX hosted VM's I still use the '/usr/sbin/sys-unconfig' ...
It does exactly what is says on the tin.
### never delete any of your cribs ###
- just dug out the procedure; from the back of an olde backup
Here it is in all of it's splendour
##############################
Pre-work.
Get the ufsdumps on a server on a local network. Ie one of the ssp's.
The images need to be on the 192.168.42.x network or you will have to plumb up
another interface later on the public.
1) Create the /etc/ethers entries for global and local mac adresses for the domain.
2) Add the entries for the domains ip in /etc/hosts
3) Setup the client as an jumpstart client using add_install_client.
4) Bringup -A off the domain and if 2.6 limit-ecache-size.
5) show-nets to select the correct interface and add a nvalias to sspnet.
6) boot sspnet -s
7) format and select the root disk. Should be a nice c0t0d0s2 :)
8) slice it up as you want and label it.
9) newfs the slices you made.
10) nfs mount the ufsdump directory onto /mnt
11) mount the root slice onto /a
12) cd /a; ufsrestore -xf /mnt/root-ufsdump
13) Stop veritas from coming up.
# touch /a/etc/vx/reconfig.d/state.d/install-db
# rm -f /a/etc/vx/reconfig.d/state.d/root-done
14) Comment out veritas and disk suite entries for rootdisk from /a/etc/system
# TERM=sun-cmd; export TERM; vi /a/etc/system
* rootdev:/pseudo/md@0:0,40,blk for disksuite
* set md:mddb_bootlist1="sd:7:16 sd:15:16 sd:23:16 sd:31:16" for disksuite
* rootdev:/pseudo/vxio@0:0 for veritas
* set vxio:vol_rootdev_is_volume=1 for veritas
15) Copy the good path_to_inst to the old root dir
# cp -p /etc/path_to_inst /a/etc/path_to_inst
16) Remove the old devices tree and dsk/rdsk entries.
# rm -rf /a/devices/*
# rm -rf /a/dev/dsk/*
# rm -rf /a/dev/rdsk/*
17) Recreate those trees for Solaris 2.6.
# drvconfig -r /a/devices -p /a/etc/path_to_inst
# cd /devices
# find . -print | cpio -pduVm /a/devices
# disks -r /a
# devlinks -r /a
18) Recreate those trees for Solaris 7 / 8 / 9.
# rm -f /a/dev/cfg/c*
# devfsadm -c disk -r /a -p /a/etc/path_to_inst
19) Sort out the /a/etc/vfstab and change to the underlying devices.
Hash out vxvm volumes or disk suite volumes.
20) Setup the boot block
# installboot /usr/platform/`uname -i`/lib/fs/ufs/bootblk /dev/rdsk/c0t0d0s0
21) Sort out the network or the reboot will take lots of time due to nis+ and dns.
Just edit the /a/etc/hosts and /a/etc/hostname.* files to reflect the new values.
22) Sort out the defaultrouter + don't route
# echo "default ip addr" > /a/etc/defaultrouter
# touch /a/etc/notrouter
23) Sort out the /a/etc/ssphostname. Put the admin network name of the main ssp.
The default is main_ssp with a corresponding entry in the /a/etc/hosts file.
Use the 192.168.42.x value for the ssp address.
24) Stop the VCS cluster form starting.
# mv /a/etc/rc2.d/S92gab /a/etc/rc2.d/s92gab
# mv /a/etc/rc2.d/S70llt /a/etc/rc2.d/s70llt
# mv /a/etc/rc3.d/S99vcs /a/etc/rc3.d/s99vcs
25) Edit /a/etc/syslog.conf and remove the chainsaw entry
26) Restore the other filesystems.
# cd /
# umount /a
# mount /dev/dsk/c0t0d0s6 /a
# cd /a; ufsrestore -xvf /mnt/var-ufsdump
27) Umount all filesystems and reboot the box with the reconfigure option.
# umount /a
# umount /mnt
# luxadm set_boot_dev /dev/dsk/c0t0d0s0
28) Setup the eeprom
# eeprom "local-mac-address?=true"
29) Sort out the dns entries (XXX = mpc/jgc/mit)
# rcp -p sda:/etc/resolv.conf.XXX /etc/resolv.conf
30) Reconfigure verbose reboot
# reboot -- -rv
31) The first reboot will fail the interfaces, this is because the reconfigure has not
sorted out the qfe in /dev/ before the kernel tries to mount it. Sorted on next reboot
or manual configure.
32) Install veritas the standard way.
... but ifconfig still only shows the loopback adapter. This is because the sysconfig networking scripts (located at /etc/sysconfig/networking-scripts/ifcfg-eth*) haven't been updated with the new MAC address.
Not necessarily.
Probably slightly cowboy, but you can use the udev files to associate MAC addresses with eth0/1/2 etc as you say, then in the ifcfg-eth0 configuration files not use a MAC address - ie once udev has sorted them out you just have ifcfg-eth0 not tied to a MAC address.
Someone will tell me that the world will end if I do this, but I've been happily running systems like this for years.
It's there and it's free ... and works on all flavours
With Ksar you can produce .pdf reports of your systems performance [great for producing charts to then explain to your 'off-shore' developers that it's not the tin underperforming it's their single threaded java app'.
So you are a Linux beginner and the first thing you want to do is to "clone virtual machines" ? Yeah, sounds like the best recipe for a M$-sponsored Badmouthing Exercise. I guess that is the whole point of the article. Windows is much better in the bribing business, as there is more money involved than in the Linux business.
So you want to really learn something new ? Remember how you did it in school: Go to the library or bookshop and get yourself a tutorial book. One that explains concepts as opposed to explaining dumb-down GUIs.
Unixoid systems (and thereby Linux) are all about
A) understanding key concepts such as files, STDIN, STDOUT, root vs normal user, permission bits, processes and the like, device files, file systems, regular expressions and the like
B) a small set of powerful commands/tools such as rm, ln, mv, vi, ps, ls, kill, grep, perl, cat. xargs, cut, split, sed. Learn those key commands/tools properly and how to combine them. They are NOT AT ALL cryptic to those who have actually taken time to learn them. They will allow you to automate lots of repetitive stuff and be much more productive than any blinking, shining GUI.
If you really need GUIs, then please stick to Windows, the OS of the MBA Generation.
OK, as I came into Linux from Unix anyway, I already had a number of fave commands which worked well going over, including find (especially find . -exec which is damn useful for things like large scale permission fixes), grep and such.
One tool I was introduced to, however, was webmin (www.webmin.com) which is a web based front end which I've used on various flavours of Linux including openSUSE and RedHat/Fedora. It cuts a lot of time and effort out of the everyday configuration tasks on a system. Certainly with SuSE, I can combine procedures using Webmin and YaST, but Webmin takes a lot of the need for tools like YaST and its equivalents on other systems out of the equation.
I'm also something of a fan these days of Nagios (www.nagios.org), amonitoring tool which can be used to monitor quite a large range of devices, from switches up to servers, Linux, Unix or Windows. I tend to use Nagios Core and build my system from there.
I switched after 18 years of CSH, TCSH and BASH, and it was worth it, even if just for the double-asterisk.
Other top old-timer tricks - to copy a whole directory between machines without rsync:
tar czf - srcdir | ssh remotehost tar zvxf -
I still get murmurs of approval for that one. And my other favourite for batch renaming files:
1. ls -1 | awk '{ print "\""$1"\"" }' > file1
3. cp file1 file2
4. vi file2 to edit the filenames with regex as you need to; then
5. paste file1 file2 > file3
6. vi file3 to insert "mv " at the start of each line.
7. source file3 to run it.
Oh and another one: avahi (which implements zeroconf)
Really. for small to mid size networks, avahi makes managing IP addresses a thing of the past. Just give the machine a name then "aptitude install avahi-utils", then you can "ssh newhost.local" without ever needing to know the IP address. I saw someone above mention dhcpd over static IP address - that's fixing exactly half the problem. Avahi fixes the other half.
Packages are essential to the long-term stability of a system. Knowing what you've got and how it got to be there are essential.
It's vital not to be distracted by the ".deb vs .rpm" "debate"[1]. They're equivalent. With one *possible* exception[2], anyone telling you that one or the other is better simply doesn't know how to drive the one he's slagging off.
When I was getting to know Linux, I broke a number of installations by relying on the advice of people who told me just to "make install" eveything. It works - for a little while. Then you find out you've over-written something that another application relied on...
Vic.
[1] I use the term quite wrongly, of course.
[2] I'm not sure it's possible to find out how a package's files have changed since installation in the apt/dpkg world; the equivalent of "rpm -V". This might just be ahole in my knowledge, but I didn't get any answers when I asked the LUG...
For the time when you hit return on
Do Not Do This@Anytime home$ rm -rf *
and then shriek "Oh, good gracious me, what a silly billy" (or words to that effect) there's <a href="http://carlo17.home.xs4all.nl/howto/undelete_ext3.html>ext3grep</a>.
You are still deep in a world of pain and toil, but all is not lost. I did this a couple of years ago (I thought I was in a subdirectory, was in fact in my home directory) and eventually I lost hardly anything, although rm had been running for about five seconds before I reached the shriek stage. Now I have ext3grep installed on a live USB stick, but I do lots of backups...
<boffin icon, because you're not giving this job to a noob>
I almost suffered badly from a simpler mistake, but logged in as an ordinary user thankfully not much happened. I was lucky that time, so don't try this folks:
chmod -R <somesetting> .*
I wanted to change settings on all hidden files/directories in my home folder, but I had not anticipated that '..' is also a match to '.*' and so the recursive application went UP a directory then down everyone else's home!
So think VERY CAREFULLY about wildcard/regex matches before doing something like this, and maybe test on a begin action before something almost irreversible like rm/chmod/chown.
One of the very first items I install on a Debian based machine is 'sysv-rc-conf' which gives a nice overview of all services and their runlevels. There's also 'rcconf' on Deb based boxes which is similar to ntsysv on RH based boxes, but you can't select the individual runlevel to run at, just simply enable/disable. Then of course there's chkconfig on RH boxes to set individual levels for services...
Surprised no one has brought up OMD yet (omdistro.org) for monitoring, which incorporates nagios, check_mk, pnp4nagios and few other tools, which makes monitoring a breeze.
htop is also a neat tool, I tend to replace top with htop on my machines by aliasing htop to top.
If you connect to many boxes via ssh, look into setting up the ssh config file, followed by an alias in your ${SHELL}rc file, e.g. alias box1='ssh box1' where box1 again is set in /home/$LUSER/.ssh/config with the settings required.
If you have to work with netcat a lot, consider swapping netcat for cryptcat (http://sourceforge.net/projects/cryptcat/)
deborphan is a useful tool for deb based boxes, finding orphaned deb installations which are no longer required.
of course learning awk and sed etc. is a given, though consider there are also other useful tools to use instead, such as tr in various cases rather than sed.
Get to know Kerberos. At some point in your SysAdm life you'll come across a large network with multiple users and systems, and you don't want to have every person having local accounts on each boxes accessed by ssh keys only...
Ideally learn to harden Linux machines from early on, makes life later on much easier too.
Also get yourself familiar with a version control system such as cvs,svn,git,mercury, and keep your config files in there, especially useful if you have a given config setting across various boxes, be it httpd confs, kerberos confs (nsswitch.conf, pam/system-auth, etc....), and any other used across various boxes.
Linux is not Windows, but it doesn't mean it's 100% safe/secure. Look into chkrootkit and rkhunter.
There are loads more of course. A forum I frequent and is quite useful is
linuxquestions.org
Enjoy,
A
My advice would be that if you are touching an individual machine, then you are losing.
For servers that means Puppet, Nagios, single signon, a brutal approach to hardware failure, funnelling everything through a ticketing system, referring to that as the documentation for changes in your configuration repo, documentation written for use by trained people rather than blow-by-blow. Because you end up with a low headcount, then that means evolution of hardware, not once-in-a-blue-moon refresh projects.
For desktops that means either SOA for BYOD, but not some expensive middle ground. It means automating the common helpdesk tasks. It means using the vendor's tools rather than third-party tools, because that lowers your training costs because users get good hits from Google. It means online training.
For networking it means DHCP for IPv4 and Dynamic DNS. It means IPv6 is standard for intranet use (ie, no interior NAT). It means not fiddling with ethernet autonegotiation. It means anycast DNS forwarders. It means cookie cutter cupboard, building and core designs. It means treating VM servers as first class items in the network. It means 802.1x for wireless rather than web landing pages.
I'm learning all this stuff for fun in my spare time.
I've found TLDP really helpful. I'm going to try a LFS build as soon as I'm happier with vi - I actually learned to ed (for fun), which came in really handy for learning to grep. I'm working my way through distros that force me to learn before I'm happy (then I move on) - started with Linux Mint, moved onto a Debian minimal install, now I'm making Gentoo my personal distro.
As a complete beginner, man pages would just blur in front of my eyes. Now I read them like novels, gasping with delight when I find a useful new switch!
grep, regex, TLDP "guide"books, wikibooks, LPI Essentials Guide (from linupfront) and generally googling for "advanced [keyword] tutorial" like bash, zsh, grep, regex, globbing were all helpful. I tried getting books out of the library, but they were all stuff I knew, except for Networking for Dummies, which was a big help for a complete noob like me learning TCP/IP principles (even though it's Windows based, the standards are all the same) and it's good for when things with ipconfig comes up.
That's me, anyway...
I know it's actually a few OSes and some tools on a CD, but man, those two have most of the tools I use. I haven't looked at Kali yet.
It's kind of funny asking for tools that an nix admin find useful. I would say "all of them". It might seem obvious to the more experienced. In order to do serious work, you'll need to use many tools. So it would be better to ask for something more specific like: "Best network traffic analysis tools". Then you might get some useful answers.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
