I've been a sysadmin for a few years in a Linux environment. I had never touched Linux prior to that. I would like to say that the quickest way is to break things. When you break it and have to fix it, you learn the subject better. Obviously don't try this on the production box :)
Everyone's environment is radically different. At my last job we had LDAP & Active Directory. At my current job we have Active Directory + NIS. There are a few constants like DNS, DHCP that you should probably learn, but beyond that you've got chef, cfengine, puppet and spacewalk, and that's just for package management. There's so many different permutations of setting the environment up that you can't learn it unless you learn as you go.
Some constants:
- vi - always installed
- (ba)sh - It's the default shell in most places, though I have seen csh
- perl - also always installed
- DNS - Most groups with a sysadmin have DNS rather than NetBIOS type resolution of names
- SMB - Because you have your Windows users
- NFS - Linux file sharing
- DHCP - Some people use AD for DHCP and then just static the Linux boxes as it's easier, and you get autoregistration in DNS. For folks with more Linux boxes you might have a Linux DHCP server.
- AD - You'd be hard pressed to find a pure *Nix shop
- LDAP - Depending on the situation, AD could be primary or these could be 2 standalone authentication systems with matching accounts.
To add to the constants list: rsync, some sort of firewall (iptables, apf-firewall, etc.), netstat, sed, awk, logrotate, lsof.
Hanging out with other sysadmins is better than a book. I find that information in books becomes outdated pretty quickly. Try new stuff in a development environment, and then pray they work the same when you go to production (often they won't - so follow the golden rule - back up everything).
Comments
I've been a sysadmin for a few years in a Linux environment. I had never touched Linux prior to that. I would like to say that the quickest way is to break things. When you break it and have to fix it, you learn the subject better. Obviously don't try this on the production box :)
Everyone's environment is radically different. At my last job we had LDAP & Active Directory. At my current job we have Active Directory + NIS. There are a few constants like DNS, DHCP that you should probably learn, but beyond that you've got chef, cfengine, puppet and spacewalk, and that's just for package management. There's so many different permutations of setting the environment up that you can't learn it unless you learn as you go.
Some constants:
- vi - always installed
- (ba)sh - It's the default shell in most places, though I have seen csh
- perl - also always installed
- DNS - Most groups with a sysadmin have DNS rather than NetBIOS type resolution of names
- SMB - Because you have your Windows users
- NFS - Linux file sharing
- DHCP - Some people use AD for DHCP and then just static the Linux boxes as it's easier, and you get autoregistration in DNS. For folks with more Linux boxes you might have a Linux DHCP server.
- AD - You'd be hard pressed to find a pure *Nix shop
- LDAP - Depending on the situation, AD could be primary or these could be 2 standalone authentication systems with matching accounts.
To add to the constants list: rsync, some sort of firewall (iptables, apf-firewall, etc.), netstat, sed, awk, logrotate, lsof.
Hanging out with other sysadmins is better than a book. I find that information in books becomes outdated pretty quickly. Try new stuff in a development environment, and then pray they work the same when you go to production (often they won't - so follow the golden rule - back up everything).